Passing the Uber system design interview for real-time dispatch

Walking into an Uber system design interview means leaving standard CRUD applications at the door. You'll be asked to architect a platform that juggles millions of concurrent geospatial reads and writes, orchestrates complex state machines across distributed nodes, and fires off split-second routing decisions. The real-time dispatch and matching system—historically known at Uber as DISCO—sits right at the heart of this challenge. Nailing a senior-level round requires proving you can tame extreme write-heavy workloads, dodge race conditions, and accurately apply geospatial indexing algorithms.

Defining Core Requirements and Scale Estimations

Don't touch that whiteboard marker until you've clearly established the system's boundaries. Strong candidates immediately draw a line between ephemeral, high-throughput location ingestion and the highly consistent, transactional ride-matching process. Your scale estimations aren't just trivia; they need to explicitly justify the architectural choices you're about to make.

• Functional Requirements: Drivers constantly broadcast their current locations. Riders request rides. The system matches each rider with the optimal nearby driver based on ETA, then actively tracks the ongoing trip state.
• Non-Functional Requirements: You need high availability for the matching system and sub-second latency for dispatching. Ride matching demands strong consistency so you don't double-book a driver. However, eventual consistency is perfectly fine for driver location updates.
• Scale Estimations: We'll assume 5 million active drivers globally alongside 20 million daily rides. If every active driver fires off a location ping every 4 seconds, your ingestion pipeline alone has to chew through over 1.25 million writes per second.

Geospatial Indexing: Why H3 Hexagons Beat Traditional Databases

The rookie mistake here is trying to find nearby drivers by querying a SQL database using latitude and longitude bounds. Push 1.25 million writes per second through that setup, and it will bottleneck instantly. Modern ride-hailing architectures fix this by relying on spatial indexing, which converts two-dimensional coordinates into one-dimensional string hashes. Geohash tackles this with rectangles, and Google S2 uses a spherical projection paired with a Hilbert curve. Uber, however, developed and open-sourced H3—a hierarchical hexagonal grid system. Hexagons win out mathematically for radius searches because the distance from the center of a hexagon to all of its neighboring centers is identical. That perfectly uniform distance eliminates the frustrating edge-case distortions you get with Geohash rectangles.

Architecting the Real-Time Location Ingestion Pipeline

Surviving the massive flood of driver location pings means entirely decoupling ingestion from processing. Mobile clients should hold open persistent WebSocket connections with an API Gateway, which drastically cuts down on handshake overhead. The gateway then fires those location payloads straight into a distributed message queue like Apache Kafka. Think of Kafka as a massive shock absorber that stops traffic spikes from crushing your downstream services. From there, stream processing frameworks like Apache Flink pull the events from the queue. Flink calculates the driver's current H3 index and pushes that fresh state into a blazing-fast, in-memory datastore like Redis for real-time queries. At the same time, it asynchronously dumps the historical location data into a wide-column store like Cassandra so the analytics teams can do their jobs later.

The Driver-Rider Matching Algorithm

The moment a rider requests a trip, the Dispatch Service grabs their coordinates and calculates the corresponding H3 index. It hits Redis to pull a list of all available drivers currently sitting inside the rider's hexagon, along with the immediate surrounding ring of hexagons. But here's the catch: physical proximity rarely equals time proximity. One-way streets, heavy traffic, and uncrossable rivers completely warp travel times. To fix this, the Dispatch Service hands its shortlist over to a Routing Service, which crunches the actual Estimated Time of Arrival using a complex routing graph. Finally, the platform ranks those drivers based on the calculated ETA, specific driver preferences, and current surge conditions before firing off a ride offer to the absolute best candidate.

Mitigating Concurrency Conflicts and Double Bookings

Ignoring concurrency is a guaranteed way to fail this interview. Think about what happens if two riders standing in a crowded downtown area get matched with the exact same driver at the exact same millisecond. You can't just rely on traditional database transactions across distributed microservices because they are painfully slow at this scale. You have to implement distributed locking.

1. Once the Dispatch Service picks a driver, it tries to grab a distributed lock on that specific DriverID using Redis SETNX, applying a very short time-to-live.
2. If the lock succeeds, the platform pushes the ride offer down to the driver's phone over WebSockets and waits for an acceptance payload.
3. If the lock fails, another dispatch process is clearly already busy offering a trip to this driver. Your system needs to immediately skip them and try locking the next best driver on the ranked ETA list.
4. If the driver rejects the request or the short timeout expires, the system drops the lock. The state machine then kicks in and transitions the rider's request to the next available driver.

Balancing Latency vs Consistency in Distributed Systems

Every system design choice comes down to trade-offs, and here, you absolutely have to bifurcate your consistency models. Tracking driver locations works perfectly fine with eventual consistency. If a little car icon on the map lags by two seconds, the app still functions normally, which means you can safely rely on asynchronous replication for location data. The ride-matching state machine is a completely different story—it demands strong consistency. A driver literally cannot be assigned to two overlapping trips at once. By completely isolating the highly available, eventually consistent location pipeline from the strongly consistent, CP-oriented matching and locking pipeline, you manage to optimize both latency and reliability.

Navigating Dynamic Trade-offs Under Pressure

Rattling off these concepts in a vacuum is easy enough, but adapting them on the fly when an interviewer throws a massive constraint at you is what actually gets you hired. They might ask you how the system handles localized network partitions when 80,000 people leave a stadium event all at once. They might tell you to suddenly pivot the entire architecture to support batch-matching for something like UberPool. Whatever they throw at you, be ready to defend the architectural boundaries you established and confidently adjust your data models in real time.