Gateway IIoT resiliente con store-and-forward

Un gateway store-and-forward sirve cuando telemetría debe cruzar una WAN intermitente sin convertir la nube en parte del control de máquina. Su función es conservar un conjunto acotado de registros hasta que vuelva la ruta aguas arriba. No promete pérdida cero: un disco puede fallar, un corte puede interrumpir escritura, la capacidad es finita y un publish MQTT aceptado no prueba que una aplicación aguas abajo guardó el registro.

Definí primero el contrato de registro

Una cola no puede recuperar significado ausente al ingreso. Cada registro aceptado necesita event_id, source, sequence dentro de una época de fuente cuando exista, measured_at, received_at, quality y versión de schema. El tiempo medido describe la observación de fuente; el recibido, la admisión local. Mantenelos separados para que una entrega tardía sea visible y no se reescriba como medición fresca.

Definí qué mensajes pueden entrar. Telemetría muestreada, transiciones de alarma, snapshots de configuración y eventos diagnósticos tienen reglas distintas de retención, orden y pérdida. Un comando no es otro tipo de mensaje. Comandos y decisiones de seguridad quedan en controlador, enclavamientos locales aprobados y personal autorizado.

Construí la ruta durable

La ruta normal es source hacia durable queue, publisher, acuse del broker y delete o mark sent. Persistí antes de considerar aceptado un registro. El publicador lee sólo entradas completas, envía lote acotado y avanza la marca de enviado sólo después del acuse MQTT configurado. Una caída entre acuse y marca puede duplicar; diseñá consumidores que lo toleren.

No uses buffer de memoria para un requisito de caída que incluye reinicio o pérdida de energía. Persistencia en disco incorpora permisos, cifrado en reposo, desgaste, reserva de sistema de archivos y recuperación de corrupción. El diseño debe decir qué falla cubre en vez de llamar durable a cualquier buffer.

Dimensioná la cola con presupuesto de caída

Partí de capacidad mayor o igual a rate por average payload por outage window por safety factor. Para 20 registros por segundo, 600 bytes codificados promedio, cuatro horas y factor 1,5, el presupuesto de payload es 20 × 600 × 14.400 × 1,5 = 259.200.000 bytes, aproximadamente 247 MiB.

Ese número no es asignación de disco. Sumá índices de cola, cabeceras de registro, overhead de cifrado o base, rotación de logs, diagnósticos retenidos y margen libre para sistema operativo. Recalculá desde tasa pico y agregá velocidad de drenaje tras caída. Una cola que publica sólo a la velocidad a la que recibe nunca se recupera.

Persistí con seguridad ante reinicio

Usá formato con longitud, validación de integridad adecuada y límite de commit atómico. Al iniciar, recorré registros, aceptá sólo entradas completas comprometidas, aislá segmentos corruptos e informá la brecha. No supongas válido un registro parcialmente escrito porque su payload parezca parseable.

Exponé estados online, buffering, draining, degraded y stopped. Draining debe seguir aceptando datos nuevos dentro de límites sin dejar que replay antiguo monopolice CPU, disco o ancho de banda del broker. Un reinicio debe recuperar el estado documentado, no descartar trabajo desconocido silenciosamente.

Reproducí en orden sin asumir exactamente una vez

Conservá orden por fuente cuando el contrato consumidor lo requiera. Orden global entre fuentes independientes rara vez existe o aporta. Publicá lotes acotados, limitá replay junto a tráfico actual y usá backoff exponencial con techo cuando el broker rechaza o no puede aceptar trabajo.

El consumidor debe deduplicar con source más event_id, o con época de secuencia documentada y regla idempotente. El orden de llegada no reemplaza orden de fuente. QoS MQTT cambia entrega de transporte, pero no elimina duplicados entre reinicio, reconexión o procesamiento de aplicación.

Hacé visible el agotamiento

Cada clase necesita política visible para TTL vencido, disco lleno, backpressure del publisher y registros malformados. Telemetría puede descartar muestras antiguas y crear brecha explícita. Eventos valiosos pueden detener ingreso y elevar alarma de salud. Rechazados pueden ir a dead-letter acotado con motivo, fuente y conteo; esa ubicación también necesita límite de retención.

Nunca expulses registros silenciosamente porque el volumen incomoda. Informá resultado de la política en métricas y documentación operativa. Disco lleno puede afectar servicios más allá del gateway, por eso reservá espacio y alertá antes del umbral del sistema operativo.

Observá salud, no sólo conectividad

Medí profundidad y bytes, edad del registro más viejo, disco libre, aceptados y rechazados, vencimientos TTL, duplicados, reintentos, latencia de publicación, profundidad dead-letter y fallas de recuperación. Informá salud que identifique online, buffering, draining o degraded.

Una sesión TCP verde no basta. No dice nada sobre fuente vencida, cola bloqueada, persistencia fallida, autorización rechazada o consumidor aguas abajo. Usá diagnósticos acotados que no expongan credenciales, claves privadas ni payload operativo irrestricto.

Probá la matriz de fallas

Probá caída prevista aguas arriba, reinicio mientras bufferiza, reinicio mientras drena, disco lleno, fallo de escritura, segmento corrupto, publicación duplicada, llegada reordenada, TTL vencido y backpressure del broker. Para cada caso, definí estado esperado, comportamiento aceptado o rechazado, señal de salud y recuperación.

Estas pruebas empiezan offline o en integración aislada. No validan tiempo de scan PLC, dinámica de planta, instalación eléctrica ni función de seguridad. La puesta en marcha configurada necesita autorización y aceptación propias.

Desplegá y revertí con criterio

Antes de desplegar, tomá línea de base de formato de cola, retención, endpoint broker, identidad TLS, ACL, ubicación de disco, reserva y contrato de fuente. Definí quién puede detener ingreso, preservar almacén viejo, restaurar versión anterior y confirmar que recuperación no reprodujo comandos.

Usá este checklist: verificá reserva libre; verificá un contrato de fuente de solo lectura; simulá caída; confirmá alarmas de edad y profundidad; confirmá drenaje acotado; confirmá duplicados; confirmá TTL y disco lleno; y registrá brechas. Seguí con diseño de payload MQTT, convergencia IT/OT y servicios IIoT cloud.