Arquitectura resiliente para sistema de peaje en el borde

Un estudio de arquitectura para un sistema de peaje en carretera donde el carril no puede esperar a la nube. Cámaras OCR y lectores RFID alimentan un proceso local en .NET Core que tiene que levantar o bajar una barrera en menos de 200 milisegundos, persistir cada evento en SQLite local, y reconciliar con un backend en la nube por MQTT cuando la conectividad lo permita — incluso después de horas sin conexión.

Un vehículo que se acerca a un carril de peaje a velocidad le da al sistema una ventana fija y muy corta para identificarlo y decidir si la barrera abre. Ese presupuesto — menos de 200 milisegundos — es más pequeño que un solo viaje redondo a un servicio en la nube en un buen día, y los sitios en carretera no tienen buenos días de forma confiable.

La consecuencia de equivocarse es física. Un carril que deja de funcionar porque un enlace está caído no es un servicio degradado: es una fila de vehículos detenidos sobre una carretera.

Este es un proyecto de arquitectura e ingeniería académica. No es un sistema de peaje comercial desplegado, y las cifras de abajo son objetivos de diseño y no mediciones tomadas de hardware de carretera en operación.

Cada pregunta de diseño aquí se desprende de una sola ubicación: la decisión de levantar la barrera se toma en el carril, usando datos que el carril ya tiene, y nada de esa decisión espera a la red.

Eso invierte el arreglo habitual. La nube no es el sistema de registro que el borde consulta — es un consumidor de eventos que el borde ya confirmó. La conectividad pasa a ser una propiedad que afecta qué tan rápido se pone al día la vista central, nunca si un vehículo puede pasar.

La distinción importa porque un búfer de reintento dimensionado para un corte breve es un componente distinto de uno dimensionado para una caída prolongada. Segundos de desconexión se pueden mantener en memoria y reproducir. Horas no: el búfer tiene que sobrevivir a un reinicio de proceso y a un corte de energía, lo que lo convierte en un problema de persistencia y no de red.

SQLite local hace entonces doble trabajo. Es el registro operativo del carril y es la cola de salida. Un evento es durable en el momento en que se toma la decisión, y la sincronización es una preocupación separada que lee de ahí — así que la ruta de código que decide si una barrera abre no contiene ninguna operación de red.

OCR y RFID fallan distinto. Una lectura de tag es rápida e inequívoca cuando hay tag y es inútil cuando no lo hay; el reconocimiento de placa funciona para cualquier vehículo pero se degrada con clima, luz, velocidad y estado de la placa.

Correr ambos no es redundancia por sí misma — es cobertura de dos modos de falla disjuntos. Sí implica que el carril puede sostener dos identificaciones de confianza distinta dentro de la misma ventana de decisión, y resolver ese conflicto es parte de la lógica local y no algo que se difiere a la nube, porque diferirlo rompería el presupuesto de latencia.