System Design Interview
Maps platform inspired by Google Maps' published techniques: pre-rendered vector tiles on a CDN, S2-cell geospatial search, live traffic from map-matched GPS pings, routing with contraction hierarchies, and historical-speed ETA prediction. A teaching design.
See why rendering tiles, scanning places and searching the whole road network per request can't work.
What was missing: Nothing yet.
Why that's risky: Rendering a tile takes far longer than serving one, a distance scan touches every place, and continental Dijkstra takes seconds.
What gets added: One server that renders tiles from the road database, finds nearby places by computing distances, and runs Dijkstra over the whole road network per route.
Trade-offs: Everything is always up to date, at enormous compute cost per request.
Serve the map from the edge and answer 'near me' with a spatial index.
What was missing: Tiles were rendered per request and nearby search scanned every place.
Why that's risky: There is no traffic data and no routing yet.
What gets added: Vector tiles pre-rendered for every zoom level into tile storage, served by a CDN with a tile service as origin, and a places service that looks up the user's S2 cells in a geospatial index.
Trade-offs: Pre-rendered tiles lag map edits until the next rebuild of affected tiles.
Turn phones' GPS pings into live speeds for every road.
What was missing: No knowledge of current road conditions.
Why that's risky: Live speeds exist but nothing computes routes with them.
What gets added: A location ingest service that appends batched GPS pings to a stream, a writer that persists them per trip, and a road matcher that snaps pings to road segments and aggregates current speeds into a live traffic store.
Trade-offs: Speeds are averaged over a few minutes, so a sudden jam shows up after a short delay.
Answer directions in milliseconds using live speeds.
What was missing: No routing.
Why that's risky: ETAs assume today's speeds hold for the whole trip, which is wrong for long drives into rush hour.
What gets added: A routing service that keeps the road graph with precomputed shortcuts (contraction hierarchies) in memory and weights segments by live speed; the graph is rebuilt nightly into a road graph store.
Trade-offs: Shortcuts take hours to precompute, so road changes appear the next day; live speeds adjust weights without rebuilding.
Predict arrival times for when the driver will actually be on each road.
What was missing: ETAs used only current speeds.
Why that's risky: Any app key can flood search or routing, and nobody tracks ETA accuracy.
What gets added: A historical speed builder producing typical speeds per segment for each hour of the week, and an ETA predictor combining live speeds near the start with historical speeds for the time each later segment will be reached.
Trade-offs: Prediction adds a few milliseconds per route in exchange for much better ETAs.
Protect shared services and watch quality.
What was missing: No per-client limits and no quality metrics.
Why that's risky: Remaining risk is regional: routing and traffic should fail over to another region's copy.
What gets added: Quotas per app key and device, and monitoring of tile hit rate, search and routing latency, ping lag and ETA error.
Trade-offs: Quotas can cut off a buggy partner app; limits are per key with alerts before cutoff.
You're in the middle of an interview session. Leaving now will end your current attempt.
Explore concept overviews, real-system examples, key tradeoffs, and interview talking points for each roadmap section.
You've conquered this phase. These are the skills you now own:
