HowWeBuiltaReal-TimeGPSPlatformThatHandles10M+RequestsaMinute
A real-time GPS platform that holds 250,000+ daily active users and 10M+ requests a minute at peak while tracking 30,000+ vehicles, and the scale engineering that keeps the live map smooth.
This is the scale story behind Pixytan, the real-time GPS platform we built and run. It holds 250,000+ daily active users and absorbs 10M+ requests a minute at its busiest, all while tracking 30,000+ vehicles live. The numbers above are real and they are ours. The rest of the page is the engineering that makes a live map stay smooth when that many devices write and that many people watch at the same time, the calls we made, and what the load taught us.
The Problem With Real-Time at Scale
A tracking platform looks easy until the second axis shows up. One vehicle on a map is a weekend project. The hard part is the day you have tens of thousands of vehicles writing position and sensor data on a short cycle, and at the same time a quarter of a million people opening apps and dashboards to watch those vehicles live. Two firehoses pointed at the same system, one writing and one reading, both peaking at the same rush hour.
The naive build points all of it at one database. Every device write lands there, every dashboard read pulls from there, and for a while it holds. Then the fleet grows, the user base grows, and one busy minute pushes the load past ten million messages and API calls. The single database becomes the bottleneck the whole product dies on. Queries crawl, the live map freezes, and the thing people opened to watch in real time is suddenly thirty seconds behind reality.
And the failure is the worst kind, because it shows up exactly when it matters most. Real-time platforms do not crash on a quiet Sunday. They crash at peak, when every vehicle is moving and every user is watching, which is the one moment the product has to be flawless. So the whole engineering problem is not making it work. It is making it not buckle under its own busiest minute.
What We Designed and Built
We split the write path and the read path so they never compete. Vehicles push data over MQTT into AWS IoT Core, where a horizontally scaled tier of Node.js workers picks it up, runs the processing, and writes the history in batches to TimescaleDB. Separately, the live state of every vehicle, its current position, speed, and status, lives in Redis with a short TTL. The expensive ingestion and the cheap live read run on different tracks and stop fighting over the same resource.
The read side is where the user numbers get held. A quarter of a million people watching live never touch the main database. They connect over WebSocket and listen, and when a vehicle moves, Redis pub or sub fans that single update out to everyone subscribed to it. One position change reaches a thousand watching screens as one publish, not a thousand database queries. That fan-out is the difference between a platform that holds 250,000 users and one that falls over at 10,000.
Every tier that can be stateless is stateless and sits behind a load balancer, so a peak adds instances instead of melting a machine. The ingestion workers scale on message volume. The API layer scales on user traffic. The WebSocket tier scales on open connections. Each piece scales on its own axis, which means a spike in one does not drag the others down. When the peak passes, the instances spin back down, because paying for rush-hour capacity at midnight is just waste.
MQTT, AWS IoT Core, Node.js, Redis (live state and pub or sub), TimescaleDB, PostgreSQL, WebSocket, load balancers, Flutter apps, React dashboard, Google Maps API, custom GPS hardware
The Decisions That Mattered
Separating reads from writes was the first and biggest call. The instinct is to keep one database as the single source of truth for everything, and at small scale that is correct. At this volume it is fatal. We made TimescaleDB the system of record and the history store, and made Redis the live layer that every dashboard actually reads from. The database stopped being the thing a quarter of a million people query and went back to doing what databases are good at.
Batching the writes was the second. Tens of thousands of devices writing one row each on a short cycle is millions of tiny inserts, and tiny inserts are how you bleed a database to death. We buffer incoming readings and write them to TimescaleDB hypertables in batches. Fewer, larger writes keep the ingestion tier ahead of the firehose, and the time-partitioned hypertables keep those writes fast even as the history grows into the billions of rows.
MQTT over plain HTTP carried the device side. At ten million messages a minute, opening a fresh connection per message is a non-starter, because the handshake overhead alone would sink it. MQTT holds a persistent connection with almost nothing spent per message, which is exactly what a constant stream of small device reports needs. The protocol was built for fleets of devices at volume, so we leaned on it instead of forcing a request-response pattern where it does not fit.
WebSocket fan-out over polling was the call that held the user count. Polling means every client asks for updates on a timer whether or not anything changed, and a quarter of a million clients polling is a self-inflicted denial of service. WebSocket flips it. The client opens one connection and waits, and the server pushes only when there is something new. Pair that with Redis pub or sub and a single vehicle update reaches everyone watching it as one message, not one query per viewer.
What Gets Built
Horizontally Scaled Ingestion
A tier of stateless Node.js workers consumes the MQTT stream, runs the per-message processing, and batches the writes. The tier scales on message volume, so a rush-hour surge adds workers and the backlog never builds. Because the workers hold no state, an instance can die mid-peak and the load balancer routes around it without a single dropped vehicle. The whole tier is designed to be cattle, not pets.
Redis Live-State Layer
Every vehicle's current position, speed, heading, and status sits in Redis with a short TTL. Open any dashboard and the live fleet renders from memory, never from the main database. This one layer is what lets 250,000+ people watch live at once, because reads land on an in-memory store built for exactly this and the slow path stays untouched.
WebSocket Fan-Out
Dashboards and apps hold a persistent WebSocket and listen. When a vehicle moves, Redis pub or sub pushes that one update to every subscriber at once. A single position change becomes a single publish that fans out to a thousand watching screens, instead of a thousand separate requests. This is the mechanism that keeps the live map current without the request count exploding with the audience.
Time-Series History at Volume
TimescaleDB hypertables partition the sensor and position history by time, so the queries people actually run, last hour, last day, last route, stay fast even as the table grows into the billions of rows. Older data compresses itself, which keeps storage from running away. The history is always there for reports and replay without ever slowing down the live path in front of it.
Load-Balanced API Tier
The REST and app-facing API runs stateless behind a load balancer and scales on user traffic on its own axis, independent of ingestion. A spike in people opening the app adds API instances without touching the device pipeline, and the two never starve each other. Health checks pull bad instances out automatically, so a single failing node never becomes a user-facing outage.
Flutter Apps Built for Spotty Networks
The driver and manager apps are Flutter, and they assume the network will drop, because in the field it does. They cache the last known state, queue actions while offline, and reconnect the socket and resync the moment signal returns. At a quarter of a million users, a lot of them are in dead zones at any given second, so the app is built to degrade gracefully instead of throwing an error and losing the thread.
The Real Result
These are the real, live numbers from the platform we run, not design targets and not a projection. This is what the architecture above is holding up today, every day, while the live map stays smooth through the busiest minute.
| Measure | Result | What Holds It |
|---|---|---|
| Daily active users | 250,000+ | Redis live layer plus WebSocket fan-out |
| Peak load | 10M+ req / min | Horizontally scaled tiers behind load balancers |
| Vehicles tracked | 30,000+ | MQTT to AWS IoT Core, persistent connections |
| Read path | Off the database | In-memory live state, never queried from Postgres |
| Write path | Batched | TimescaleDB hypertables, partitioned by time |
| Scaling shape | Out, not up | Stateless services that add instances on demand |
Where Else This Pattern Fits
The architecture under this platform is not really about vehicles. It is a real-time ingestion and fan-out pipeline, and that shape powers a lot of products that look nothing like a fleet on the surface. A write-heavy stream of events feeding a read-heavy live view is the common thread, and once you see it you see it everywhere.
Ride-hailing maps watching thousands of drivers move, live logistics and delivery dashboards, IoT sensor floors on a factory, live sports and trading tickers, multiplayer presence, real-time analytics that update as events land. All of them have the same core tension we solved here. Many things write fast, many people read live, and the database cannot be on the hot path for both. If that describes your product, this is the engineering that holds it up.
Frequently Asked Questions
What does 10M+ requests a minute actually mean here?
It is the peak inbound load the platform absorbs in a busy minute across two streams. Tens of thousands of vehicles report position and sensor data on a short cycle, and hundreds of thousands of people open the apps and dashboards to watch live. Add those together at rush hour and the number climbs past ten million messages and API calls a minute. The whole architecture exists to take that peak without the live map stuttering.
How do you hold 250,000 daily active users on a tracking platform?
You keep the read path off the main database. Every vehicle's current position and status lives in Redis with a short TTL, and the dashboard listens over WebSocket instead of polling. So a quarter of a million people watching live are reading from an in-memory layer that fans the same update out to everyone who cares about that vehicle, not hammering Postgres a quarter of a million times. The expensive write path and the cheap read path stay separate on purpose.
Why not just scale a single server up?
Because one box has a ceiling and you hit it. A real-time GPS platform at this volume needs to scale out, not up. We run the ingestion workers, the API layer, and the WebSocket fan-out as separate horizontally scaled services behind load balancers, so a traffic spike adds instances instead of melting one machine. Stateless services where we can, sticky sessions only where the socket needs them. That is what lets the platform ride a peak and shed the instances again when it passes.
What breaks first when a real-time platform scales?
The database, almost always. Teams point every read and write at one Postgres instance and it falls over the moment live traffic gets real. The fix is to stop treating the database as the live layer. Writes batch into TimescaleDB hypertables, live state sits in Redis, and the dashboards read from Redis over WebSocket. The database becomes the system of record and the history store, not the thing a quarter of a million people query every few seconds.
What technology stack runs a real-time platform at this scale?
MQTT to AWS IoT Core for device ingestion, a Node.js processing tier that scales horizontally, Redis for live state and pub or sub fan-out, TimescaleDB for the time-series history, and WebSocket to push updates to screens. Flutter for the driver and manager apps, a React dashboard for dispatch, and load balancers in front of every stateless tier. The shape is built so each piece scales on its own axis.
Can Geminate Solutions build a real-time platform that scales like this?
Yes. We run a real GPS platform that holds 250,000+ daily active users and 10M+ requests a minute at peak while tracking 30,000+ vehicles, and Geminate Solutions has shipped 50+ products. The ingestion pipeline, the Redis live layer, the WebSocket fan-out, and the horizontal scaling are patterns we design and build with our team. Tell us your expected load and we will tell you honestly what the architecture needs. Start at geminatesolutions.com/get-started for a free project assessment.
Does this only apply to vehicle tracking?
No. The shape underneath it is a real-time ingestion and fan-out pipeline, and it powers far more than fleets. The same architecture runs live sports and logistics dashboards, IoT sensor floors, ride-hailing maps, and any product where a lot of devices write fast and a lot of people read live. If your platform has a write-heavy stream feeding a read-heavy live view, this is the pattern that holds it up.
Why Teams Bring This to Us
Scaling a real-time platform is a different skill from building one, and the gap usually shows up in production at the worst possible time. Plenty of teams ship a tracking feature that works beautifully in a demo and then watch it fold the first time real traffic arrives. The fixes, separating reads from writes, batching, a Redis live layer, WebSocket fan-out, are not exotic, but knowing to design them in from the start is the difference between a platform that scales and a rewrite under fire.
We bring the scars. We run a platform at 250,000+ daily active users and 10M+ requests a minute, so the architecture on this page is not theory, it is what is holding our own production load right now. We build with you as a product partner, not a code shop taking a spec over the wall, which means the call to keep the database off the hot path, or to batch the writes, or to fan out over WebSocket, comes from us before the peak forces it. That is the point of building it with a team that has already been through the load.
Related Resources
- Fleet Management for 30,000+ VehiclesThe hardware and fuel-anomaly side of the same Pixytan platform
- IoT GPS Tracking System Case StudyAnother IoT build with hardware and software in one stack
- Custom Software Development ServicesHow we build and ship products with our team
- Logistics Software DevelopmentTracking, routing, and operations for fleets and delivery
Need a platform that holds up at scale?
The ingestion pipeline, the Redis live layer, the WebSocket fan-out, and the horizontal scaling on this page are the same ones we build with our team for your product. We run a real GPS platform at 250,000+ daily active users and 10M+ requests a minute, and Geminate Solutions has shipped 50+ products. Tell us your expected load and we will tell you honestly what the architecture needs.