Ingesta IoT que espera duplicados, desorden y desconexiones
Un listener que recibe mensajes no es todavía una plataforma de ingesta. La confiabilidad aparece cuando el flujo conserva identidad, tiempo, errores y capacidad de replay.
Flujo de referencia
- Dispositivosidentidad · timestamp · secuencia
- Listenersadaptadores de protocolo
- Busparticiones · retención · backpressure
- Procesamientovalidación · deduplicación · ventanas
- Persistenciaseries · eventos · estado
- Consumoalertas · APIs · analítica
Semántica antes que tecnología
Cada evento necesita una identidad estable, origen, tiempo del dispositivo y tiempo de recepción. Sin esos campos, los duplicados y el orden no pueden resolverse de forma defendible.
- Idempotencia con claves de evento o secuencia.
- Orden por dispositivo o partición; no prometer orden global.
- Ventanas y tolerancia para eventos atrasados.
- Validación de esquema antes de enriquecer.
Fallos que deben poder recuperarse
Los retries deben ser acotados. Los eventos agotados pasan a dead-letter con contexto suficiente para diagnóstico y replay; no se descartan ni se reintentan para siempre.
- Backpressure cuando la entrada supera el procesamiento.
- Dead-letter con causa, payload seguro y correlación.
- Replay controlado sin duplicar efectos.
- Desconexiones tratadas como comportamiento normal.
Observabilidad operativa
La observabilidad debe distinguir mensajes recibidos, válidos, duplicados, atrasados, rechazados y pendientes. Una sola métrica de throughput esconde los fallos que importan.
- Lag por partición o consumidor.
- Edad del evento más antiguo pendiente.
- Tasa de duplicados y rechazos.
- Alertas sobre SLOs del flujo, no sobre ruido individual.