What is Interview Forge?

Interview Forge helps you practice mock interviews, follow study plans, track career goals, review learning analytics, and prepare across 36 pages.

Design Uber (Ride-Hailing) at Google — System Design Interview Guide

The problem at Google

Functional: riders request a ride, nearby drivers are matched, a driver accepts, the trip is tracked live, fare is computed and charged, ratings are exchanged.
Non-functional: low-latency matching (<3s), high availability, accurate ETA, consistent and auditable pricing, fair dispatch.
Scale: millions of drivers and riders, ~10M trips/day in a large metro, ~100K driver location updates/sec.
Consistency: driver location is eventually consistent (last-write-wins with a short TTL is fine); trip state and fare must be strongly consistent.

Out of scope (covered in detail below)

Driver onboarding/verification, in-app payments plumbing, marketing, pool/shared rides, and scheduled rides — deferred and discussed in the dedicated section.

At Google, this problem is framed around algorithmic rigor and generalist problem-solving. Expect Google-specific scale numbers and a focus on production readiness and the company's engineering bar.

Capacity estimation

Resource	Estimate	Notes
Driver location updates	~100K/s	Each driver pings every 3-5s
Ride requests	~1K/s peak	10M trips/day, concentrated at rush hours
Live trip tracking	~1M concurrent trips	Each emits location updates
Geospatial index size	~tens of GB	Driver id -> (lat,lng), TTL ~10s

Architecture overview

Dispatch & tracking architecture

+----------+   GPS ping   +---------------+   +-------------------+
| Driver   |------------->| Location      |-->| Geospatial Index  |
| App      |              | Ingestion Svc |   | (Redis GEO/S2)    |
+----------+              +---------------+   +-------------------+
                                                    ^
+----------+   request     +---------------+        |   nearby drivers
| Rider    |------------->| Dispatch Svc  |--------+
| App      |              +---------------+
+----------+                     | accept (first wins)
                                  v
                          +---------------+        +---------------+
                          | Trip Service  |------->| Pricing Svc   |
                          | (state machine|        | (surge)       |
                          +---------------+        +---------------+
                                  |
                                  v
                          +---------------+
                          | Payment Svc   |
                          +---------------+

Location ingestion is decoupled from dispatch; the geospatial index is the hot path.

Step-by-step request flow

Driver app sends GPS pings (every 3-5s) to the location ingestion service, which upserts (driver_id -> lat,lng) in the geospatial index with a short TTL.
Rider requests a ride; the dispatch service queries the geospatial index for the nearest N available drivers (the rider's geocell + neighbors).
Dispatch broadcasts a trip offer to those drivers; the first to accept wins (optimistic concurrency — the others are cancelled).
The trip service drives the state machine: requested -> accepted -> en_route -> ongoing -> completed, persisting each transition.
On completion, the pricing service computes the fare (base + time + distance + surge) and the payment service charges the rider and pays the driver.

Unlock the full guide

Premium members get every DSA, system design, company and role interview guide — plus AI practice, mock interviews, and analytics.

Unlock with Premium