Heavy Lifting + Your Rehearsal
The rehearsal: design it cold
The whiteboard is blank again — but this time nothing you draw will be new. Every box, you have drawn before, in pieces, across five modules. The prompt is fresh: design a ride-share backend. The moves are not. Let’s run the whole playbook, cold, and watch it hold.
- Functional: a rider requests a trip; the system matches a nearby driver; both sides see live location and an ETA; a price is quoted up front and charged at the end.
- Scope aggressively: no pooling, no scheduled rides, no surge-pricing internals, no payment reconciliation. One city-scale core loop done well beats ten features sketched badly.
- Non-functional: matching within a few seconds, location updates that feel live, and zero lost trips — money and people are involved.
Rides: 1M per day ÷ 86,400 ≈ 12 ride events per second on average; at a 10× evening peak, ~120/s — one solid database shrugs. Locations are the monster: 500K active drivers sending one ping every 4 seconds ≈ 125,000 writes per second, sustained, all day. Riders poll positions too, so reads on that same data run into the hundreds of thousands per second. Storage is a footnote — 100 bytes per ping × 125K/s ≈ 1 TB a day, most of it worthless within minutes. Conclusion: location data cannot touch the main database.
Notice what just happened: you did not choose an architecture — the arithmetic did. 12 rides/s says boring relational store with replicas; 125K location writes/s says a fast, volatile, geo-aware store with short-lived entries. Estimation is not the warm-up. It is the design.
Six boxes. Rider and driver apps talk to an API layer. A location service ingests pings into a geo index and answers “who is near this point.” A matching service takes a request, queries the geo index, and offers the trip to drivers in order. A trip service owns trips in a relational database — requested, ongoing, completed. Payments and receipts fire asynchronously through a queue when a trip completes, and live positions flow to both apps over WebSocket connections. Every box is a pattern you already own.
The hardest question hides inside matching: find available drivers within 2 km, fast. A naive scan computes distance to all 500K drivers per request — dead on arrival. A geohash encodes a coordinate as a string where nearby points share prefixes, so “drivers near me” becomes a prefix lookup plus the 8 neighboring cells to catch edge cases. A quadtree applies the same idea spatially: recursively quarter the map, keep drivers in leaf cells, and a search descends only the branches that matter. Both turn an O(everything) scan into an O(nearby) lookup.
In the room, you do not design a geohash library. You say: PostGIS if it lives in the relational store, Redis GEO if it lives in memory, S2 if the team already runs it — and you spend your minutes on the trade-off that matters: how fresh is “nearby,” and what happens when a matched driver never answers. Knowing the primitive exists, and what it costs, is the senior move.
One question for the whole course: given 45 minutes and a blank board, what do you do — and which defaults must already live in your head? (Run the playbook in order: scope requirements, estimate with 86,400 seconds a day and honest ratios, sketch boxes, deep-dive the hardest one. Carry the defaults: cache the hot 20% that drives 80% of reads, put a CDN in front of static and popular content, shard only when one machine can’t absorb the writes or the bytes, set quorums with R + W > N when reads must see writes, and choose push versus pull fanout by where the write cost belongs. The framework is the answer; the numbers are its fuel.)
Five modules, one arc: the foundations of scale taught you why systems bend; the playbook gave you the four steps; distributed data primitives handed you replication, partitioning, and consensus; product-scale systems showed the patterns working together; and the heavy lifting — plus this rehearsal — proved the moves transfer to a prompt you have never seen. The whiteboard was never the subject. Your judgment was.
Pick a real system at your job — an internal tool, a pipeline, a feature you ship every sprint. Write its one-page design doc using the playbook: requirements in three bullets, back-of-envelope estimates with real numbers from your logs, a box sketch, and one deep dive on the component that genuinely worries you. Then share it with one colleague and argue about it. That argument is the course, continuing.
Heavy Lifting + Your Rehearsal