Problems / Real world, hard
Asked at Uber and Lyft. Drivers ping their location every few seconds, riders ask for ETAs and request rides, and all of it goes through one API to one PostGIS database. At 10 s a concert lets out and traffic rises 80%.
Unlock it once for 25 credits; everything inside it is free (runs, changes, Submit, results, hints). Sign in with Google to start; new accounts get free credits.
Success ≥ 99.5%, p99 ≤ 800 ms and Apdex ≥ 0.90 through the surge, for at most $26,000 a month.
Like a coding problem, a solution has to pass every case, not just the one it was built for. Submit in the lab runs all 4; 1 of them are hidden until then.
30,000 requests a second for 20 seconds: 85% ping (writes), 10% eta (reads), 5% match (writes).
What each component does in this design, and what calls it. The simulator mimics each one from these settings.
| Component | Its job here | Settings |
|---|---|---|
| Load balancerLoad balancer | Traffic enters here.Calls Dispatch API.Layer 4 balancers route by IP and port; layer 7 balancers read HTTP and can route by path or header. | – |
| Dispatch APIApp service | Load balancer forwards to it.Calls Drivers and trips (Postgres with PostGIS).Little's law: throughput ≈ concurrency ÷ latency. 200 slots at 50 ms serve about 4,000 req/s. | 16 replicas × 100 slots · timeout 1.0 s |
| Drivers and trips (Postgres with PostGIS)SQL database | Dispatch API calls it.Postgres runs one process per connection, which is why poolers like PgBouncer sit in front of busy databases. | 32 vCPU · 800 connections |