ADR-0002 — Protocolo de ingesta: HTTP por lotes

Contexto

Miles de sensores generan lecturas de forma sostenida. Esos datos tienen que llegar a la capa de ingesta, que los valida, autentica al emisor, los persiste y los publica hacia la capa de streaming.

Hay que decidir el protocolo de transporte entre el sensor y la ingesta. La decisión condiciona la interfaz pública del sistema, el cliente que emite las lecturas, la operativa (autenticación, cifrado, monitorización), la forma de devolver errores al productor y el equilibrio entre curva de aprendizaje y valor demostrado.

Un dato relevante del contexto: los sensores son simulados, sin las restricciones de firmware, memoria o batería del hardware real. Además, la entrega de una demo que arranque de forma limpia y sin dependencias pesadas es un requisito.

Decisión

Se adopta HTTP por lotes como protocolo único de ingesta. Cada petición transporta un conjunto de lecturas (típicamente un centenar), se autentica mediante una clave de API y se valida de forma rigurosa y síncrona: el lote entero se acepta o se rechaza con un error detallado que indica exactamente qué falla. Se aplica limitación de tasa y contrapresión explícita: cuando la capa de streaming o el almacén se saturan, la ingesta responde con una señal clara para que el cliente reduzca el ritmo.

Como complemento (no sustituto) se contempla un puente MQTT opcional: un servicio aparte que se suscribe a los mensajes MQTT de clientes reales y los reencamina hacia la misma ingesta. Así se demuestra el conocimiento del estándar IoT sin comprometer la vía principal.

No se adoptan gRPC, WebSocket ni protocolos binarios propios.

Consecuencias

Positivas:

• Validación rica y síncrona: el emisor recibe de inmediato un error preciso con el campo problemático, lo que hace trivial la depuración.
• Observabilidad uniforme: cada petición es una traza más dentro del mismo sistema de métricas que el resto del backend.
• Contrapresión explícita mediante códigos de estado semánticos.
• Demo sin fricción: la ingesta se puede probar con una simple petición HTTP o desde la documentación interactiva, sin clientes propietarios.
• El agrupamiento por lotes reduce el número de peticiones a un nivel que la infraestructura absorbe con enorme holgura.

Negativas o costes aceptados:

• La vía principal no es el protocolo "estándar de IoT"; se compensa con el puente MQTT opcional.
• HTTP añade cierta sobrecarga por petición frente a un protocolo binario, irrelevante con el agrupamiento por lotes y solo relevante a tasas muy altas.
• No hay publicación/suscripción nativa; ese papel lo cubre la capa de streaming.

Alternativas descartadas

• MQTT como vía principal: es el estándar de facto en IoT industrial y eficiente sobre redes inestables, pero añade un servicio crítico (el broker), complica la autenticación, retrasa la validación hasta el consumidor (sin respuesta síncrona al productor) y dificulta la demo. Se conserva como puente opcional para clientes reales.
• gRPC en streaming: muy eficiente y fuertemente tipado, pero introduce generación de código, depuración más difícil y complejidad gratuita para el caso de uso.
• WebSocket: la conexión persistente convierte la ingesta en un servicio con estado (miles de conexiones vivas), complica el escalado y no aporta sobre el lote HTTP.
• Protocolo binario propio sobre TCP/UDP: máxima eficiencia a cambio de reimplementar todo lo que HTTP y TLS ya resuelven; sin estándares ni tooling.