You open your phone, press "Confirm Ride," and within 3 seconds, a driver is assigned to you.
As a user, it feels like magic. As a software engineer, you know it is a chaotic symphony of microservices, geospatial indexing, and real-time data streams.
If you tried to build Uber using a standard monolithic architecture and a SQL database, your server would crash the moment you hit 1,000 concurrent users. You cannot simply run a query like SELECT * FROM drivers WHERE location = 'Lagos' AND distance < 5km. The database would lock up instantly.
So, how does Uber actually do it? Let's break down the architecture.
1. The Geospatial Problem: H3 (The Hexagon Grid)
Uber’s biggest challenge is calculating distance instantly. To solve this, they created and open-sourced H3, a Hexagonal Hierarchical Spatial Index.
Instead of calculating the exact latitude and longitude of every user against every driver, Uber divides the entire Earth into a grid of hexagons.
The Magic: When you open the app, Uber instantly knows which "hexagon" you are standing in.
The Match: It then only searches for drivers who are pinging their location inside your specific hexagon (and the immediate neighboring hexagons). This turns a massive, computationally heavy math problem into a simple, lightning-fast dictionary lookup.
2. The Data Firehose: Kafka
Drivers send their GPS coordinates to Uber's servers every 4 seconds. Imagine 1 million drivers online. That is 250,000 write requests per second.
No standard database can handle that directly.
The Solution: Uber uses Apache Kafka. Kafka acts as a massive shock absorber. It ingests the millions of GPS pings, queues them up, and streams them to the mapping services and databases without dropping a single packet of data.
3. The Matchmaker: WebSockets and DISCO
When you request a ride, your phone establishes a persistent WebSocket connection with Uber’s Dispatch System (internally called DISCO).
Why WebSockets? HTTP requests are too slow for real-time tracking because they require opening and closing a connection every time. WebSockets keep the tunnel open, allowing the server to push the driver's live location to your screen continuously.
The Logic: DISCO looks at the active drivers in your H3 hexagon, filters out those already on a trip, and sends a push notification to the closest driver.
4. The Memory: Cassandra
Where do you store billions of completed trips, ratings, and driver logs?
Uber uses Apache Cassandra, a highly scalable NoSQL database.
Cassandra is designed for high-write environments. It allows Uber to store petabytes of trip data across multiple data centers globally, ensuring that even if an entire server farm in Europe goes offline, the app stays up.
Summary Architecture Table
Component Technology Purpose in the System
Location Tracking H3 (Hexagons) Lightning-fast geospatial lookups.
Data Ingestion Apache Kafka Handling 250k+ GPS pings per second.
Real-Time Comms WebSockets Live map updates without refreshing.
Database Storage Cassandra Highly available, distributed data storage.
Conclusion
Uber is not just an app; it is a massive distributed system handling extreme scale. The next time you order a ride and watch that little car move on your screen, you’ll know exactly the data pipeline powering it.
Hi, I'm Frank Oge. I build high-performance software and write about the tech that powers it. If you enjoyed this, check out more of my work at frankoge.com
Top comments (0)