Caso de estudio · TECOM 2026
Del hardware a la nube: 7.000 máquinas hablando a la vez
Cómo funciona el sistema de Micronauta que recibe, ordena y guarda los datos de toda una flota de colectivos (posiciones GPS y pagos) sin perder una sola trama, incluso en hora pico. Lo investigué de punta a punta para contarlo en TECOM 2026.
- Mi parte
- Mejoré la web de la flota y armé la charla
- Escala
- ~7.000 máquinas a bordo
- Pico
- ~1.400 tramas por segundo
- Infraestructura
- 11 servidores (9 locales + 2 virtuales)
El problema
Cada colectivo lleva una máquina a bordo que registra su posición GPS y cada pago, y lo manda por red celular. Un urbano reporta cada ~3 segundos; un interurbano, cada ~6.
El desafío no es una máquina: es que miles hablen a la vez, todo el día, y que nada se pierda. Una trama de transacción es plata: si se pierde, la recaudación no cierra.
La trama: cada byte cuenta
Las máquinas no mandan JSON: mandan tramas binarias compactas, de 40 a 1.200 bytes. Por red celular, un formato de texto multiplicaría el tráfico y el costo. Cada trama ya trae adentro qué tipo de dato es y de qué máquina viene.
El ACK: el permiso para avanzar
La máquina guarda cada trama en su propia cola y la manda de a una. Solo pasa a la siguiente cuando el servidor le responde ACK («la tengo, seguí»). Si se queda sin señal, sigue registrando y reenvía todo cuando vuelve la conexión.
La arquitectura
Dos microservicios y una pila en el medio. La entrada tiene que ser rápida; el procesamiento, ordenado. Separar esas dos cosas es lo que hace que el sistema aguante los picos.
01
Máquina
a bordo del colectivo
02
Micro TCP
recibe y responde ACK
+ TCP de respaldo
03
La pila
cola que absorbe picos
04
Micro FAZ
enruta por cliente
05
Base del cliente
escrituras
06
Réplica
lecturas del front
Micro TCP: la puerta de entrada
Liviana a propósito: no procesa nada. Recibe la trama, responde el ACK y la deja en la pila. Así la máquina nunca espera a que la base termine de escribir.
La pila: el amortiguador
Una base que funciona como cola. Si en un pico entran más tramas de las que se pueden procesar, esperan ahí, en orden. La TCP apila y la FAZ desapila: nadie se pisa.
Micro FAZ: el repartidor
Saca tramas de la pila, las interpreta y pone cada dato en la base de su cliente según el ID que viene en la trama. Trabaja a su ritmo: si hay pico, la pila espera.
Réplica: leer sin molestar
Cada base tiene una copia espejo. La FAZ escribe en la principal y el front consulta la réplica, así una consulta pesada nunca frena la escritura. Y si la principal falla, los datos siguen ahí.
Las decisiones que lo hicieron escalar
- 01
Todo en el mismo servidor
Se probó separar la TCP, la FAZ y las bases en servidores distintos. El traspaso de datos por la red local era tanto que la red colapsaba. Juntos, los datos viajan por dentro del servidor.
- 02
Una base por cliente
Los datos de un cliente nunca comparten base con otro: separación física, no solo lógica. Es seguridad y, además, escalabilidad. Un cliente grande recibe su propia FAZ y no frena al resto.
- 03
Siempre hay respaldo
Si la TCP principal se cae, una de respaldo toma el flujo y el camino sigue igual. La máquina ni se entera.
- 04
La máquina pregunta, el servidor responde
Para mandarle horarios o un firmware nuevo no se le habla directo: la orden queda pendiente en la base y viaja junto con el próximo ACK. Lo que no puede esperar, como el mapa del pasajero, va por WebSockets.
Un día cualquiera
- máquinas en la calle
- ~7.000
- máquinas en la calle
- tramas en hora pico
- ~1.400/s
- tramas en hora pico
- guardados y replicados por día
- ~30 GB
- guardados y replicados por día
- tramas perdidas: ninguna se da por entregada sin ACK
- 0
- tramas perdidas: ninguna se da por entregada sin ACK
Mi parte
Este sistema ya existía cuando llegué. Mi trabajo fue mejorar la web de la flota, donde el equipo de soporte ve cada coche en el mapa, revisa reportes y manda órdenes a las máquinas. Para la charla, que presentamos en equipo en TECOM 2026, investigué cómo funcionaba todo el recorrido dentro de la empresa, armé la presentación y expuse el lado servidor.
Ver la charla