Case study · TECOM 2026
From hardware to the cloud: 7,000 machines talking at once
How Micronauta's system receives, sorts and stores data from an entire bus fleet (GPS positions and payments) without losing a single frame, even at rush hour. I researched it end to end to present it at TECOM 2026.
- My part
- Improved the fleet web app and built the talk
- Scale
- ~7,000 on-board machines
- Peak
- ~1,400 frames per second
- Infrastructure
- 11 servers (9 on-prem + 2 virtual)
The problem
Every bus carries an on-board machine that records its GPS position and every payment, and sends it over the cellular network. A city bus reports every ~3 seconds; an intercity bus, every ~6.
The challenge isn't one machine: it's thousands talking at once, all day long, with nothing lost. A transaction frame is money: if it's lost, the fare collection doesn't add up.
The frame: every byte counts
The machines don't send JSON: they send compact binary frames, 40 to 1,200 bytes long. Over a cellular network, a text format would multiply traffic and cost. Each frame already carries its data type and the machine it comes from.
The ACK: permission to move on
The machine keeps every frame in its own queue and sends them one at a time. It only moves to the next one when the server answers ACK ("got it, go on"). If it loses signal, it keeps recording and resends everything once the connection is back.
The architecture
Two microservices with a queue in the middle. Ingestion has to be fast; processing has to be orderly. Splitting those two concerns is what lets the system absorb the peaks.
01
Machine
on board the bus
02
Micro TCP
receives and ACKs
+ Backup TCP
03
The queue
absorbs peaks
04
Micro FAZ
routes per client
05
Client database
writes
06
Replica
front-end reads
Micro TCP: the front door
Lightweight on purpose: it does no processing. It receives the frame, answers the ACK and drops it in the queue, so a machine never waits for the database to finish writing.
The queue: the shock absorber
A database working as a queue. If more frames arrive at peak than can be processed, they wait there, in order. TCP pushes and FAZ pops: they never step on each other.
Micro FAZ: the dispatcher
It pulls frames from the queue, parses them and writes each record into its client database based on the ID inside the frame. It works at its own pace: at peak, the queue waits.
Replica: read without getting in the way
Every database has a mirror copy. FAZ writes to the primary and the front end reads from the replica, so a heavy query never slows down writes. And if the primary fails, the data is still there.
The decisions that made it scale
- 01
Everything on the same server
Splitting TCP, FAZ and the databases across different servers was tried. So much data moved over the local network that it collapsed. Together, data travels inside the server.
- 02
One database per client
One client's data never shares a database with another's: physical isolation, not just logical. That's security and also scalability. A large client gets its own FAZ and doesn't slow anyone down.
- 03
There is always a backup
If the primary TCP goes down, a backup one takes over the stream and the path stays the same. The machine doesn't even notice.
- 04
The machine asks, the server answers
To send it schedules or new firmware we never talk to it directly: the order waits in the database and rides along with the next ACK. What can't wait, like the passenger map, goes over WebSockets.
Any given day
- machines on the street
- ~7,000
- machines on the street
- frames at rush hour
- ~1,400/s
- frames at rush hour
- stored and replicated per day
- ~30 GB
- stored and replicated per day
- lost frames: none counts as delivered without an ACK
- 0
- lost frames: none counts as delivered without an ACK
My part
This system was already running when I joined. My work was improving the fleet web app, where the support team sees every bus on the map, reviews reports and sends orders to the machines. For the talk, which we presented as a team at TECOM 2026, I researched how the whole pipeline worked across the company, built the slides and presented the server side.
Watch the talk (in Spanish)