Design Google Maps and a Routing Engine

This page is one interview loop in three rounds. All three rounds design the same system. Each round opens with the interviewer raising the scope, and the design from the round before has to evolve to meet it.

You can start at any round. Rounds 2 and 3 open with a "Where we left off" summary that catches you up.

Loop Opener: What Is a Maps Engine?

You Already Know One: a Paper Map, a Route Planner and a Traffic Report

Before phones, a road trip needed three things: a paper map to see where you are, a route planner (a person with the map and a pencil) to pick the roads, and the traffic report on the radio to tell you which roads to avoid right now. A maps app is those three things in one screen, and behind the screen they are three very different systems.

A few words we'll use all the way through:

• A graph is a set of points joined by lines. For roads, a node is an intersection (or a point where a road changes), an edge is a piece of road between two nodes, and an edge's weight is what it costs to drive it, usually seconds of travel time.
• A tile is one square of the map at one zoom level. At zoom 0 one tile shows the whole world; each zoom level splits every tile into 4.
• An ETA (estimated time of arrival) is our prediction of when the driver arrives.

Synthesizing vector architecture diagram...

Three systems with three different rhythms. Tiles change once a week, the road graph's shape changes once a week, but the road graph's weights change every few seconds. Most of the difficulty lives on the arrow from traffic to routing.

What Makes It Hard

• The graph is huge. A single country has tens of millions of road edges; the planet has hundreds of millions. A textbook search explores millions of them per query.
• Answers must be fast. A driver who misses a turn needs a new route before the next intersection, so a route has to come back in milliseconds, not seconds.
• The cost of every road keeps changing. The fastest shortest-path technique (preprocessing the graph so queries skip most of it) assumes the weights are fixed. Traffic changes them every minute.
• The input is noisy. GPS positions wander 5 to 15 meters or more in cities, enough to jump to the parallel road.

The Question the Whole Loop Answers

How do we find the fastest route in milliseconds on a graph whose weights change every minute?

The answer gets sharper every round:

• Round 1: pre-built vector tiles on a CDN, and a road graph held in memory with a preprocessing step (contraction hierarchies) that makes queries skip almost all of it.
• Round 2: a telemetry pipeline that turns 4 million GPS pings a second into road speeds, and a preprocessing technique that splits the graph's shape from its weights, so new weights apply in seconds.
• Round 3: the planet in regional pieces, offline maps, transit, map data from many sources, and closures that reach everyone within seconds.

---

Round 1 · Mid-level · "Maps and Directions for One Country"

~35 min · SDE II (L5) · 1 region, 3 AZs · ~24M-node road graph · 2M routes/day, 120/s peak · 54M tiles/day, 2,100/s peak · tile P99 < 100 ms · route P99 < 500 ms · 99.9%

R1.1 Establish Design Scope

The interviewer says: "We're a delivery company. Our drivers and our planners need a map and turn-by-turn routes between stops. Today we pay a vendor per request and the bill is growing. Design our own." We ask before we draw.

Out of scope for this round:

• Live traffic and ETAs that react to it.
• Rerouting drivers during a trip.
• Any country but the US, and any mode but driving.

R1.2 Functional Requirements, Derived Step by Step

Not yet: live traffic, rerouting, other countries, other modes, offline.

R1.3 Non-Functional Requirements: the Questions

• Tile latency. P99 under 100 ms. The map must follow the driver's thumb without blank squares.
• Route latency. P99 under 500 ms server time. A planner clicking through stops notices anything slower.
• Correctness. Every returned route is legal (turns, one-ways) and the fastest under our weights. A slightly slow answer is a bug report; an illegal route is an incident.
• Availability. 99.9%, about 43.8 minutes a month. If routing is down, drivers fall back to the last route their app downloaded, so this is a fair target for Round 1.

R1.4 The API

Get a map tile

A tile is addressed by three numbers, z/x/y:

• z is the zoom level. At zoom z the world is a grid of $2^z \times 2^z$ tiles.
• x is the column, counting east from longitude −180°.
• y is the row, counting south from the top edge of the map.

The map uses the Web Mercator projection (the one almost every web map uses). It stretches the globe onto a square, which only works up to about 85.05° north and south, so the poles are cut off. The formulas for a point at latitude $\varphi$ and longitude $\lambda$:

$$x = \left\lfloor \frac{\lambda + 180}{360} \cdot 2^z \right\rfloor \qquad y = \left\lfloor \frac{1 - \ln(\tan\varphi + \sec\varphi)/\pi}{2} \cdot 2^z \right\rfloor$$

Worked example: San Francisco City Hall, 37.7749° N, 122.4194° W, at zoom 14 ($2^{14} = 16{,}384$ tiles across):

• $x = (-122.4194 + 180) / 360 \times 16{,}384 = 0.15995 \times 16{,}384 = 2{,}620.6 \Rightarrow 2{,}620$
• $\tan\varphi + \sec\varphi = 0.7750 + 1.2652 = 2.0402$; $\ln 2.0402 = 0.7130$; $0.7130/\pi = 0.2270$; $(1 - 0.2270)/2 = 0.3865$; $\times 16{,}384 = 6{,}332.8 \Rightarrow 6{,}332$

So the tile is 14/2620/6332. Its parent at zoom 13 is 13/1310/3166 (halve both and round down), and its four children at zoom 15 are 15/5240/12664, 15/5241/12664, 15/5240/12665 and 15/5241/12665.

httpCopy
GET /v1/tiles/r2026-09-20/14/2620/6332.mvt HTTP/1.1
Host: tiles.maps.example
Accept-Encoding: gzip

httpCopy
HTTP/1.1 200 OK
Content-Type: application/vnd.mapbox-vector-tile
Content-Encoding: gzip
Cache-Control: public, max-age=31536000, immutable
ETag: "9f2c61d0"

• .mvt is a Mapbox Vector Tile: an open specification for a tile encoded as Protocol Buffers. It holds geometry (roads, buildings, water as points, lines and polygons in tile-local coordinates, 4,096 units across by default) plus attributes (road class, name). The phone's GPU draws it.
• r2026-09-20 is the map release. Putting it in the path makes every tile URL immutable: a new release gets new URLs, so caches can keep a tile for a year and never serve a stale one (step 1.1). Because it's in the path, the CDN's cache key includes it for free.
• The app learns the current release from a small style document (GET /v1/style.json, cached for 60 seconds), which also tells it how to color each road class.

Compute a route

httpCopy
POST /v1/routes HTTP/1.1
Host: api.maps.example
Authorization: Bearer <access token>
Content-Type: application/json

{
  "origin":      { "lat": 37.774929, "lon": -122.419416 },
  "destination": { "lat": 37.338208, "lon": -121.886329 },
  "mode": "DRIVE",
  "avoid": ["FERRIES"],
  "steps": true
}

httpCopy
HTTP/1.1 200 OK
Content-Type: application/json

{
  "route_id": "rt_01J8Z3",
  "map_release": "r2026-09-20",
  "distance_m": 77840,
  "duration_s": 2940,
  "polyline": "i|peFj`ejV...",
  "legs": [
    {
      "steps": [
        { "i": 0, "maneuver": "DEPART",    "instruction": "Head southeast on Market St", "distance_m": 450,   "duration_s": 65 },
        { "i": 1, "maneuver": "RAMP_LEFT", "instruction": "Take the ramp onto US-101 S", "distance_m": 72400, "duration_s": 2600 }
      ]
    }
  ]
}

Recap

• Tiles are addressed z/x/y in Web Mercator, and the release sits in the URL so tiles are immutable.
• One route endpoint returns a line, a duration and steps.
• About 24M nodes and 58M edges; 120 routes and 2,100 tiles a second at peak (R1.7).

Let's build it, starting with the first thing a team usually tries.

R1.5 Design Evolution: From Rendering on Request to a Graph in Memory

Every step follows the same pattern: a problem, your turn to think, the answer, and what it costs us. The cost is usually the next problem.

Step 1.0: The Baseline

A team's first version: a web server that draws a map image on every request from the map data in PostgreSQL (with the PostGIS extension), and a route endpoint that runs a recursive SQL query over a road_edges table.

Synthesizing vector architecture diagram...

Everything goes to one database: every map view draws a picture, and every route walks the road table row by row.

What's good about it: one database, one server, and it works for a demo city.

What it costs us: drawing a map image takes tens to hundreds of milliseconds of CPU, and every driver panning the map asks for it again. A recursive query explores the graph one join at a time through indexes on disk. Both get slower as the country gets bigger.

Step 1.1: "Rendering Maps on Every Request Is Slow"

Primitive: Distributed Cache Patterns and Eviction · Drill: The image service that made every origin server sweat (both questions are answered here and in R1.9: how long viewers keep seeing old content, and why a CDN beats scaling the origin)

How long until drivers stop seeing an old map? With release-versioned URLs, at most one style reload: 60 seconds after we publish a new style.json, apps ask for the new release's URLs, and the old tiles simply stop being requested. There is nothing to invalidate. If we had used unversioned URLs with a one-year cache time, drivers could see the old map for up to a year, unless we sent a CloudFront invalidation (which takes minutes to reach all edges, and costs $0.005 per path beyond the first 1,000 paths a month).

Why a CDN instead of a bigger origin? Three reasons, with numbers from R1.7:

The CDN wins on all three: it moves the bytes closer, does 95% of the work for us, and costs no more per byte.

Step 1.2: "Route Search in SQL Takes Seconds"

The graph in memory

Road names, shapes (the bends between two nodes) and turn instructions live in separate parallel arrays, indexed by edge number. The search never touches them; only the final path does. Keeping the hot fields small is what keeps the search fast.

Dijkstra's algorithm on a 6-node example

Dijkstra keeps a tentative cost for every node it has reached, and a priority queue ordered by that cost. It repeatedly takes the cheapest node, marks it settled (its cost is now final), and relaxes its edges: if going through it makes a neighbor cheaper, it lowers the neighbor's cost.

Synthesizing vector architecture diagram...

Six intersections; each edge is a two-way road with its travel time in minutes. We want the fastest route from A to F.

The route is A → C → B → D → F, 2 + 1 + 5 + 2 = 10 minutes. Following the "came from" pointers back from F gives it. Note that the direct road A–B (4) lost to the detour through C (3), and that Dijkstra settled E even though E leads nowhere useful: it settles everything closer than the target, in every direction.

textCopy
Dijkstra(source, target):
    cost[source] = 0; push (source, 0) onto the queue
    while the queue is not empty:
        (u, c) = pop the entry with the lowest c
        if c > cost[u]: skip it                  -- a stale entry; u was lowered later
        if u == target: stop
        for each edge (u -> v, w) in the slice edges[first_edge[u] .. first_edge[u+1]):
            if c + w < cost[v]:
                cost[v] = c + w; parent[v] = u
                push (v, c + w)                   -- push a new entry; don't edit old ones

The queue holds fixed (node, cost) entries. When a node gets cheaper we push a new entry and skip the stale one when it comes out. Editing an entry's cost in place without re-ordering the heap is a classic bug that returns wrong routes.

Step 1.3: "Dijkstra Explores the Whole Country"

A* on the same 6-node graph. Our guesses $h$ (straight line to F divided by top speed, in minutes): A 9, B 7, C 8, D 2, E 11, F 0. Each is at most the true remaining cost (A's true cost is 10, E's is 13).

Same route, same 10 minutes, and E is never settled: its guess says it points the wrong way. On a real map, E is Oregon.

Step 1.4: "Long Routes Still Take Hundreds of Milliseconds"

CH on the 6-node graph. We contract in the order C, E, F, A, B, D (ranks 1 to 6).

Synthesizing vector architecture diagram...

Bottom to top by rank. The forward search from A climbs A → B → D using the shortcut; the backward search from F climbs F → D. They meet at D, the highest node on the route.

The query from A to F:

1. Forward, upward from A (rank 4): A's edges to C (rank 1) and E (rank 2) go down, so they're ignored. The shortcut to B (rank 5) goes up: B = 3. From B, the edge to D (rank 6) goes up: D = 3 + 5 = 8.
2. Backward, upward from F (rank 3): the edge to D (rank 6) goes up: D = 2.
3. Meet at D: 8 + 2 = 10. Same answer as Dijkstra.
4. Unpack the shortcut A–B into A–C–B, giving A → C → B → D → F.

The two searches touched 4 nodes (A, B, D, F) instead of 6. On a country, the difference is 280 against 9.3 million.

textCopy
CH_query(s, t):
    run two Dijkstra searches, forward from s and backward from t, alternating
    each search relaxes only edges (u -> v) with rank[v] > rank[u]
    whenever a node has a cost from both sides: best = min(best, fwd[v] + bwd[v]), meet = v
    stop a side when its cheapest queue entry is >= best; stop when both sides stopped
    path = fwd path s..meet + reversed bwd path meet..t
    replace every shortcut on the path by its two halves, recursively   -- "unpacking"

Step 1.5: "The Route Turned Left Where It's Illegal"

Synthesizing vector architecture diagram...

In the node-based graph, the ban at B can't be expressed: B is one node. In the edge-based graph, the ban is a missing edge from "road C to B" to "road B to D".

Step 1.6: "Where Does the User's Tap Land on the Road?"

Primitive: Geospatial Indexing: Geohash, Quadtree, S2

Round 1 Step Summary

R1.6 Architecture v1

Synthesizing vector architecture diagram...

Two paths that share nothing at request time: tiles come from the CDN, routes from servers that hold the whole graph in memory. The only link between them is the release number.

The pieces:

• Build pipeline: a weekly job takes the map data, validates it (below), builds tiles (zoom 0–14) and the routing graph (edge-based, with CH), and writes both to S3 under the release number. It runs on one large instance for about an hour (R1.7).
• CloudFront with Origin Shield: Origin Shield is one extra cache layer in front of S3, so that a miss in many edge locations turns into one request to S3.
• Routing servers: stateless. Each holds the whole graph. The ALB spreads requests across them. Any server can answer any route.
• No database on the request path. Both tiles and routes are served from immutable, versioned files.

Validation before a release goes out (a bad map is worse than an old map):

Trace 1: a tile request

Synthesizing vector architecture diagram...

Most requests end at the edge. The shield turns many edges' misses into one read from S3.

Trace 2: a route request

Synthesizing vector architecture diagram...

Everything happens in one process, in memory. The server time is a few milliseconds against a 500 ms target.

R1.7 Numbers

Traffic

Tiles and storage

Graph memory

An r7g.large has 16 GiB, so the graph fits with room for the process and the operating system. It's RAM, not CPU cache: a CPU's L3 cache holds tens of megabytes, a thousand times less. What makes the search fast is that each step touches few, nearby memory locations.

Routing CPU. We plan on about 5 ms of CPU per route request (snap, CH query, unpacking, shapes, steps, JSON), an estimate to confirm by load test. At 120/s that's 0.6 vCPU busy. Three r7g.large servers (2 vCPUs each) run at 10% busy, and after losing an AZ the remaining two run at 15%. We have three for availability, not for load.

Preprocessing. The published edge-based CH on Western Europe took about 23 minutes on 12 cores. Our graph is about 1.4 times larger, so we plan on about 30–40 minutes on one 16-vCPU instance, plus about an hour for the tiles, once a week.

Monthly cost (us-east-1 on-demand list prices, 730 hours, 30.4 days)

Almost all of it is the CDN, and a third of the CDN bill is the per-request charge, not the bytes. The routing servers cost $235. (CloudFront's always-free allowance of 1 TB and 10 million requests a month would take about $95 off; we leave it out.)

R1.8 Trade-Offs

Search techniques (published Western Europe figures, single core, 18.0M nodes; illustrative for our graph, not promises)

Vector vs raster tiles

Graph in memory vs a graph database

R1.9 Failure Modes

R1.10 Pillar Check

R1.11 Round 1 Rubric and Follow-Ups

What a strong mid-level (L5) answer shows

• Separates the map (static, cacheable) from routing (a search) from the start.
• Explains z/x/y tiles and why vector tiles beat images, and makes tile URLs immutable with a release number.
• Puts the graph in memory as flat arrays and explains why, with a size estimate.
• Runs Dijkstra correctly on a small example, and explains how A*, bidirectional search and CH each cut the work.
• Handles turn restrictions in the graph, not after the search, and snaps to edges, not nodes.
• Says which assumption CH depends on (fixed weights).

Follow-up questions

1. "Our planners want a 100 × 100 table of travel times between all stops of one van, to optimize the stop order. Do we run 10,000 route queries?" Answer: no. CH has a many-to-many method: run one upward backward search from each of the 100 targets and store, at every node reached, "target j is this far". Then run one upward forward search from each of the 100 sources and, at every node reached, combine with the stored entries. That's 200 small searches instead of 10,000, and only distances, no shapes. Only the final chosen route needs its geometry.

2. "Why zoom 14 and not zoom 18 for the tiles?" Answer: each zoom level has 4 times the tiles of the one before, so building to 18 means $4^4 = 256$ times the zoom-14 count: about a billion tiles for the US instead of about 4 million. Vector tiles carry exact shapes, so the phone can draw zoom 18 from zoom-14 data. We'd only go deeper if zoom-14 tiles got too big in dense cities, and we can drop small details from low zooms to keep sizes in check.

3. "Could the routing server read the graph from disk instead of RAM?" Answer: memory-mapped from a local NVMe disk, yes, once the operating system has cached it; that's a common way to make startup instant. Reading it from network storage per query, no: each search step would wait on I/O. The working set is the whole graph because routes can go anywhere, so it has to live in RAM either way.

Interview gotchas from this round's wrong answers

---

Round 2 · Senior · "Live Traffic From 20M Drivers, and Fast ETAs"

~40 min · Senior SDE (L6) · 1 region (us-east-1), 3 AZs, plus the CDN · North America · 4M pings/s (6M peak) · 50M routes/day, 10,000 route computations/s planned · 1B tiles/day, 50K/s peak · route P99 < 25 ms server time · traffic reflected within 30 s · 99.95%

R2.0 Where We Left Off

This is what the candidate says aloud in the first 60 seconds of Round 2. If you're starting here, it's everything you need from Round 1.

Round 1 in 60 seconds. "A delivery company needed maps and routes for the US: a graph of about 24M nodes and 58M directed edges, 120 routes and 2,100 tiles a second at peak. Tiles are built once per weekly release as vector tiles up to zoom 14, stored in S3 under the release number and served by CloudFront, so URLs are immutable and nothing is ever invalidated; the phone draws them and overzooms past 14. Routing servers hold the whole graph in RAM as flat forward-star arrays, 16 bytes per node and per edge, renumbered along a Hilbert curve. Dijkstra settles millions of nodes, A* and bidirectional search help a little, and contraction hierarchies, which add shortcuts so a query only climbs toward important roads from both ends, cut a query to a few hundred nodes and well under a millisecond. Turn restrictions live in an edge-based graph, about 5 times the memory, and routes start on the nearest edge from a spatial index. Each server needs about 7 GB; three r7g.large servers and the CDN cost about $5,400 a month. The open cost: CH assumes fixed weights, and we have no traffic."

Architecture v1, compact

Synthesizing vector architecture diagram...

Round 1 in one picture: static tiles on a CDN, a static graph in memory, both rebuilt weekly.

Round 1 step summary

Open costs: no live traffic, no ETA beyond typical speeds, nobody gets rerouted, and CH can't take new weights without a rebuild.

R2.1 The Scope Raise

Interviewer: "The routing engine worked, so now it's our consumer maps app for North America. At a busy hour about 20 million phones have the app open in a car and share their location every 5 seconds; the busiest hours of the year reach 30 million. Routes and ETAs have to reflect traffic within about 30 seconds of it happening. When a jam or a closure appears, drivers already on their way must be rerouted. GPS is noisy in cities. We compute 50 million routes a day, with sharp rush hours, and a route has to come back in under 25 milliseconds."

We ask back, and say what each answer changes.

Scope change

It's tempting to promise "five nines" (5.26 minutes of downtime a year, about 26 seconds a month). We don't. One bad weekly release or one regional event would spend a year's budget, and the phone already carries its route through short outages. 99.95% for routing, with tiles on a CDN, is the honest target.

R2.2 What Breaks in the Round 1 Design

R2.3 New Requirements and API Additions

The telemetry ping. Phones keep one long-lived TLS connection to our ingest fleet and send a small binary frame every 5 seconds. JSON over HTTPS would cost several hundred bytes per ping in headers alone, times 4 million a second.

The server answers every ping with a 10-byte ACK frame: the acked seq, a notice flag, and a route_version when a reroute is waiting (step 2.6).

Start navigation

httpCopy
POST /v1/navigation/sessions HTTP/1.1
Host: api.maps.example
Authorization: Bearer <access token>
Content-Type: application/json

{ "route_id": "rt_01J8Z3", "device_pseudonym": "7f3a9c01e2d4b688" }

httpCopy
HTTP/1.1 201 Created
Content-Type: application/json

{ "session_id": "ns_01J8Z4Q", "route_version": 1, "expires_at": 1790571600 }

ETA in the route response. New fields:

jsonCopy
{
  "duration_s": 3120,
  "typical_duration_s": 2700,
  "delay_s": 420,
  "traffic_epoch": 179057120,
  "segments_congestion": [ { "from_i": 212, "to_i": 380, "level": "HEAVY" } ]
}

duration_s is our ETA with traffic; typical_duration_s is the same route at this time of week without live data; traffic_epoch names the weight snapshot that produced it (step 2.3).

The reroute notice. When the server has a better route for a session, the next ping's ACK carries notice = REROUTE, route_version = 4. The app then fetches it:

httpCopy
GET /v1/navigation/sessions/ns_01J8Z4Q/route?version=4 HTTP/1.1
Host: api.maps.example
Authorization: Bearer <access token>

The response is the normal route body plus reason (CLOSURE, FASTER_ROUTE) and the IDs of the closed edges, so the app can check whether the problem is still ahead of it.

Recap

• 32-byte binary pings over one long-lived connection per phone; the ACK is our way back to the phone.
• Navigation sessions with a route_version that only goes up.
• Routes carry an ETA with traffic, a typical ETA, and the weight snapshot they used.

R2.4 Design Evolution: From Fixed Weights to Live Traffic

Step 2.1: "4M Pings a Second: Where Do They Go?"

Synthesizing vector architecture diagram...

Keyed by device until the matcher, because matching needs one device's pings in order; keyed by road segment after it, because speed needs all vehicles on one road together.

Primitive: Message Queues vs Event Streams

Step 2.2: "Pings Wander Onto the Parallel Road"

A worked example. A car on motorway H, with frontage road F alongside. Three pings, 5 s apart, about 139 m apart (100 km/h). We use log-probabilities (so we add instead of multiply) and drop constants that are the same for every candidate; $\sigma = 10$ m, $\beta = 20$ m.

Transitions, $-\lvert \text{ping distance} - \text{driving distance} \rvert / 20$: staying on H differs by 2 m (−0.1); staying on F by 3 m (−0.15); switching needs the 440 m ramp, a difference of about 300 m (−15) or 350 m (−17.5).

• Nearest road says F, H, H: a jump across a barrier.
• Viterbi after ping 3 says H, H, H: the best final score is H, and its path came from H at every step.
• Deciding ping 1 after only one more ping would have said F: at ping 2 the best path still ends on F. That's why dense areas wait for two.

Synthesizing vector architecture diagram...

The thick path is the winner. Switching roads between pings costs so much that the sequence stays on one road, even though ping 1 alone looked closer to F.

Step 2.3: "Traffic Changes Weights, but CH Was Built for Fixed Weights"

Synthesizing vector architecture diagram...

A query uses real roads only inside the origin's and destination's cells (A and C) and jumps across cell B using its precomputed boundary-to-boundary cost. When traffic changes a road inside B, only B's table and its parent's are recomputed.

Keeping the weights in order. A server that restarts, or that finds an epoch missing (expired or never written), must not apply later deltas on top of a gap: a segment could keep a stale jam forever. So:

1. On start: load the latest S3 snapshot (epoch M), then apply deltas M+1, M+2 ... up to weights:latest, in order, and only then take traffic.
2. In normal running: apply epoch N+1 only after N. If N+1 is missing, reload the snapshot and catch up again, rather than skip.
3. Replays are harmless: after a Flink restart the same window can be written again under the same epoch number; a server that already passed that epoch ignores it, and because deltas carry absolute speeds, applying one twice gives the same result.

Closures are not weights. A closed bridge can't be a value in a delta: the next delta for that segment (or the blend toward the historical profile when no cars report) would reopen it, snapshots don't contain it, and the historical fallback would drop it. So each routing server keeps a separate closure overlay, loaded from the closure store (a DynamoDB table road-closures; global in Round 3). Whenever the server computes a segment's effective weight, after a delta, a snapshot reload or a switch to historical weights, the rule is the same: infinity if a closure on that segment is active by the server's own clock, otherwise the delta, snapshot or historical weight. On start, and on any snapshot reload, the server re-reads all active closures before it takes traffic. A new closure is pushed to the overlay at once (and servers re-read the table every 10 seconds as a backstop), then customizes just the cells that contain it.

The 30-second budget (worst case, dependent steps add)

"Reflected" means the first window that contains the slow cars. A 60-second window blends old and new, so a sudden stop pulls the average down a little in the first firing and fully within a minute. We accept that: reacting to one car braking would be worse.

Step 2.4: "The ETA Is Wrong at 5 pm"

Distance ÷ speed limit (105, 60 and 40 km/h) gives 5.7 + 20.0 + 7.5 = 33.2 min, 13 minutes too optimistic.

Step 2.5: "Everyone Got Rerouted Onto the Same Side Street"

Synthesizing vector architecture diagram...

Almost flat up to capacity, then very steep: a street at twice its capacity takes 3.4 times as long, at three times 13 times as long.

Keeping planned volume correct in both directions. The counts must go down as well as up, or streets look busier every hour until everything is penalized. We don't keep them as counters that routing servers increment (a retried increment counts twice, and a missed decrement never comes back). The session index (step 2.6) derives them: each session contributes +1 to each segment on its current route version with an expected passage time in the next hour. A new route version replaces the old one's contribution; an ended or expired session removes its own; a passed segment drops out when its time goes by. The index applies each session's updates in version order and ignores older versions, and it recomputes all counts from scratch every 5 minutes to catch any drift.

Step 2.6: "A Bridge Closed; 15,000 Drivers Are Headed to It"

Synthesizing vector architecture diagram...

The nearest drivers are handled in the first second and hear about it on their next ping. Nothing is sent to all 2.1M sessions.

Lost notices. Valkey's pub/sub is fire-and-forget: an ingest server that was reconnecting misses messages. So each notice is also added to a set per 10-second bucket, notices:{bucket}, kept 10 minutes; every ingest server re-reads the last bucket every 10 seconds. A phone that hasn't pinged for 30 seconds while it has a pending closure notice also gets a visible push notification ("Road closed ahead, new route available"), which is appropriate for a user-facing alert.

Primitive: Circuit Breaker, Bulkhead and Fault Tolerance Patterns (the scheduler's rate limit is a bulkhead that protects the routing fleet from its own reroute storm)

Round 2 Step Summary

R2.5 Architecture v2

Synthesizing vector architecture diagram...

Three flows meet at the routing fleet: the release graph from S3 (not drawn), live weights from Valkey every 10 seconds, and requests from phones. Tiles never touch it.

The pieces added since Round 1:

• Ingest fleet (45 × c7g.4xlarge behind an NLB with TCP pass-through): holds about 450K TLS connections each, validates frames, batches to Kinesis, and writes ACKs with notices.
• Map matchers (21 × c7g.4xlarge): Kinesis Client Library consumers, each holding the North America graph with shapes and a spatial index (about 8 GB), keeping each device's recent pings and Viterbi state in memory.
• Managed Flink (about 120 processing units): per segment, a 60-second window firing every 10 seconds; one vote per vehicle per segment per window, which both stops one idling car from outvoting ten moving ones and makes duplicate observations (from a matcher restart) harmless. It computes the harmonic mean of the vehicles' speeds (the right average for travel time over a fixed distance), requires at least 3 vehicles, and otherwise blends toward the historical profile. It validates, then writes deltas and snapshots.
• Routing fleet (21 × c7g.4xlarge): the MLD graph with turn tables, historical profile IDs, and two weight sets in memory (the one serving queries and the one being customized).
• Session API, DynamoDB, its change stream (Kinesis Data Streams for DynamoDB) and the session index, plus the reroute scheduler on ECS Fargate. The closure store and each server's closure overlay sit beside the weights.
• Traffic tiles: GET /v1/traffic/{z}/{x}/{y}.mvt with Cache-Control: max-age=30. The base tiles already carry each road's segment ID, so a traffic tile only carries "segment → congestion level" pairs, about 5 KB. A small Fargate service builds them from the latest weights.

Data model: the session item

A reroute write:

textCopy
UpdateItem ActiveNavigation
  Key: session_id = "ns_01J8Z4Q"
  Update: SET route_version = :v4, route_edges = :edges, edge_eta_offsets = :etas,
              polyline = :pl, last_closure_id = :cl
  Condition: route_version = :v3 AND expires_at > :now_from_scheduler_clock

The condition compares with a time the scheduler supplies from its own clock; DynamoDB itself has no notion of "now" in conditions.

Trace 1: a ping becoming a speed

Synthesizing vector architecture diagram...

A slowdown at 12:00:00 is in routes by about 12:00:15 here, inside the 23-second worst case.

Trace 2: a reroute on a closure. The sequence in step 2.6: the closure reaches every routing server's closure overlay within a second (it doesn't wait for the 10-second window), the index returns 15,000 sessions in well under a second, the scheduler works through them nearest-first at 1,000 a second, and each phone learns on its next ping. The last session is rerouted after about 15 s and hears within about 21 s.

R2.6 Numbers and Cost

Telemetry

The Kinesis quota check: 240 + 180 + 8 (session changes) = 428 shards, far under the default quota of 20,000 per account in us-east-1; we still check it in Service Quotas.

Navigation

Tiles

The 25 KB is an average per request, not per tile. A planet-wide build averages under 1 KB per tile, but most tiles are ocean and empty countryside; people look at cities, where tiles are tens of KB.

Routing server memory (North America)

A c7g.4xlarge has 32 GiB: the graph fits with room for the process, and new releases go out blue/green on fresh instances, so we never hold two graphs on one server.

Routing fleet. Per route computation we plan on about 10 ms of CPU (snapping, an MLD query of a few ms, alternatives, unpacking, ETA, JSON: an estimate to load-test). At 10,000/s that's 100 vCPUs busy; at a 60% target, 167 vCPUs. Each server gives 12 vCPUs to queries (4 go to customization), so we need 14 servers after losing an AZ: 7 per AZ, 21 servers.

Route latency budget (P50, one request, dependent steps add; estimates)

Monthly cost (us-east-1 on-demand list prices, 730 hours, 30.4 days)

Tiles are about $70,000 of it, and half of that is the per-request charge. The whole telemetry pipeline, from NLB to Flink, is about $55,600. Routing itself is under $9,000. Per route computation, the whole system costs about $28.5 per million (151,800 ÷ 5.32B computations a month).

Where the money is is a senior signal here: making routing faster saves little; the levers are the CDN (fewer, better-cached requests, and at this volume a committed-use discount such as CloudFront's savings bundle) and the telemetry pipeline (the NLB's per-byte charge, the ingest fleet).

R2.7 Trade-Offs

Handling changing weights (published Western Europe figures, rough and hardware-dependent; our graph is about 4 times larger)

How fine-grained speeds should be

Push vs polling for reroutes

R2.8 Failure Modes

R2.9 Production Gotchas

R2.10 Pillar Check

R2.11 Round 2 Rubric and Follow-Ups

What a senior (L6) answer adds over L5

• Explains exactly why plain CH breaks with changing weights (missing shortcuts, not just stale ones) and compares CCH and MLD with real figures.
• Builds a telemetry pipeline sized in shards and servers, keyed correctly at each stage, and rejects per-request services with the arithmetic.
• Does map matching as a sequence problem and knows the decision delay it costs.
• Proves a freshness budget end to end, stage by stage.
• Blends live and historical speeds by arrival time, and measures ETA error.
• Prevents herding with planned volume, BPR and splitting, and keeps the counts correct in both directions.
• Reroutes nearest-first in rate-limited waves, with conditional writes and retries that read state first.

Follow-up questions

1. "Why not do map matching inside Flink?" Answer: matching needs the road graph, shapes and a spatial index in memory, about 8 GB for North America, next to each device's recent pings. A Flink processing unit has 4 GB. We could split the graph by area, but then a car crossing a boundary would need its sequence handed over. A matcher fleet on larger instances, keyed by device, is simpler. Aggregation, which only needs per-segment state, fits Flink well.

2. "A city partner wants the live speed of every segment every 10 seconds." Answer: we already produce that: the deltas. We publish them to the partner as files (or a feed) with the epoch numbers, so the partner can detect gaps and reload a snapshot, exactly as our servers do. We aggregate further if the contract or privacy rules require it; one vehicle's speed on a quiet street at 3 am can identify someone, so we suppress segments with fewer than a minimum number of vehicles.

3. "What if we must honor a truck's height limit on some routes?" Answer: that's another weight set: a truck metric where low bridges and restricted roads have infinite weight. MLD's shape-independent preprocessing is shared, and each weight set costs only its own customization and about 1 GB of memory at our size. We'd keep a truck metric customized on the same 10-second deltas, or less often if trucks are few.

Interview gotchas from this round

---

Round 3 · Architect · "The Whole Planet, Offline, and Multi-Modal"

~45 min · Principal (L7) · 3 regions (us-east-1, eu-west-1, ap-southeast-1) plus the CDN · 415M-edge planet graph · 12M pings/s (18M peak) · 875M route computations/day, 50K/s planned · 4B tiles/day, 200K/s peak · closures everywhere within seconds · 99.99% per region

R3.0 Where We Left Off

This is what the candidate says aloud in the first 60 seconds of Round 3. If you're starting here, it's everything you need from Rounds 1 and 2.

Round 2 in 60 seconds. "A consumer maps app for North America: 20M phones send a 32-byte ping every 5 seconds, 4M a second, over long-lived TLS connections to an ingest fleet behind an NLB. Kinesis keyed by device feeds map matchers that run an HMM with Viterbi, deciding each ping after one or two more arrive; a second stream keyed by road segment feeds Flink, which takes one vote per vehicle per segment, a harmonic mean over 60 seconds, validates it, and every 10 seconds writes a delta of absolute speeds with an epoch number. Because plain CH gives wrong answers when weights change, routing servers run MLD: cells with precomputed boundary costs, customizing only changed cells, applying epochs strictly in order and reloading a snapshot on any gap, all within a 23-second worst case. ETAs blend live and historical speeds by when we reach each segment. Planned volume with BPR penalties and split assignment prevents herding. Closures reroute the affected sessions nearest-first at 1,000 a second, delivered in the ping ACK. About 21 routing servers for 10,000 computations a second, and about $151,800 a month, half of it tiles. Open costs: one region, one continent, driving only, one map source, and no offline use."

Architecture v2, compact

Synthesizing vector architecture diagram...

Round 2 in one picture: a live-weight pipeline feeding a customizable routing graph, for one continent.

Steps so far

Open costs: one region, one continent, driving only, one map data source, nothing offline.

R3.1 The Scope Raise

Interviewer: "We're going global. The app should work on every continent, with the data served from nearby. Users want to download a city before a trip and navigate with no signal. They want walking, cycling and public transit, not just driving."

Interviewer: "Our map data now comes from our own survey vehicles, from partners like transport agencies, and from users who report and fix things, and those sources disagree. And when a road closes, that has to show up for everyone within seconds, wherever they are."

We ask back, and say what each answer changes.

Scope change

R3.2 What Breaks in the Round 2 Design

R3.3 New Requirements and API Additions

A mode parameter. POST /v1/routes now takes mode: DRIVE, WALK, BIKE or TRANSIT, and for transit a depart_at or arrive_by time.

The offline pack manifest. An offline area is a set of pack cells. A pack cell is the area of one zoom-8 tile: about 156 km wide at the equator, about 97 km at London's latitude. Fixed cells mean packs are built once per release and shared by everyone who downloads that area.

jsonCopy
{
  "cell": "8/127/85",
  "release": "r2026-09-20",
  "expires_at": "2026-11-15T00:00:00Z",
  "parts": [
    { "kind": "tiles",  "bytes": 88400000, "sha256": "4be1...", "url": "/v1/packs/r2026-09-20/8/127/85/tiles.pmtiles" },
    { "kind": "graph",  "bytes": 41200000, "sha256": "90ac...", "url": "/v1/packs/r2026-09-20/8/127/85/graph.bin" },
    { "kind": "search", "bytes": 19800000, "sha256": "d17f...", "url": "/v1/packs/r2026-09-20/8/127/85/search.bin" }
  ],
  "diff_from": [
    { "release": "r2026-09-13", "bytes": 23900000, "url": "/v1/packs/r2026-09-20/8/127/85/diff-r2026-09-13.bin" }
  ]
}

Transit feed ingest (partners and our crawler):

httpCopy
PUT /internal/v1/transit/feeds/sg-lta HTTP/1.1
Host: ingest.maps.example
Content-Type: application/zip

<GTFS zip: stops.txt, routes.txt, trips.txt, stop_times.txt, calendar.txt ...>

httpCopy
HTTP/1.1 202 Accepted
Content-Type: application/json

{ "feed_id": "sg-lta", "version": 118, "status": "VALIDATING" }

GTFS (General Transit Feed Specification) is the standard format agencies publish timetables in: a zip of CSV files for stops, routes, trips and each trip's stop times. GTFS Realtime is its companion for live data (trip delays, vehicle positions, service alerts), encoded as Protocol Buffers.

Map edits:

httpCopy
POST /v1/map-edits HTTP/1.1
Host: api.maps.example
Authorization: Bearer <access token>
Content-Type: application/json

{
  "feature_ref": "edge:88123901",
  "change": { "attribute": "oneway", "from": "no", "to": "yes" },
  "evidence": { "photo_ids": ["ph_71c2"], "observed_at": "2026-09-27T09:12:00Z" },
  "client_release": "r2026-09-20"
}

httpCopy
HTTP/1.1 202 Accepted
Content-Type: application/json

{ "edit_id": "me_01J90A", "status": "PENDING_REVIEW", "risk": "HIGH" }

202 Accepted: an edit is a proposal, never an immediate change to the map.

Recap

• Routes take a mode; transit takes a time.
• Offline areas are made of fixed zoom-8 cells, each a versioned, checksummed, expiring pack with diffs.
• Timetables arrive as GTFS; edits arrive as proposals with evidence.

R3.4 Design Evolution: From One Continent to the Planet

Step 3.1: "The Planet Graph Doesn't Fit One Server's Budget"

Synthesizing vector architecture diagram...

The EMEA server does the search; APAC answers two small questions. Everything inside one continent stays inside one region.

Primitive: Database Sharding and Partition Keys (the same lesson: partition by the key your queries stay inside, here geography)

Step 3.2: "Offline Maps"

How big is a pack? London as an example, estimates:

Synthesizing vector architecture diagram...

The app only ever routes on a pack in Ready or Stale. An update never touches the pack in use until the new one is verified.

Step 3.3: "Transit Routing"

textCopy
RAPTOR(origin_stops_with_walk_times, depart_at, max_rounds):
    arrival[stop] = depart_at + walk time for origin stops, infinity elsewhere
    marked = origin stops
    for k = 1 .. max_rounds:
        routes_to_scan = routes serving any marked stop (from its earliest marked stop)
        marked = {}
        for each route r in routes_to_scan:
            trip = none
            for each stop p along r, from the earliest marked stop:
                if trip is set and trip's time at p < arrival[p]:
                    arrival[p] = trip's time at p; mark p          -- ride to p
                if we can catch an earlier trip of r at p (arrival_prev_round[p] <= its departure):
                    trip = the earliest such trip                    -- (re)board
        for each marked stop p: relax footpaths p -> q (arrival[p] + walk <= arrival[q])
        if nothing was marked: stop
    answer = best of arrival[stop] + walk time from stop to the destination

Step 3.4: "Map Data From Many Sources Disagrees"

Synthesizing vector architecture diagram...

No source writes to the map directly. Everything becomes a scored proposal, and the map changes only through a validated release.

Step 3.5: "A Closure Must Show Up Everywhere in Seconds"

Synthesizing vector architecture diagram...

Routes in the owning region change within about a second, other regions within a few seconds, the map display within about a minute.

Step 3.6: "Build or Buy?"

Round 3 Step Summary

R3.5 Global Architecture

Synthesizing vector architecture diagram...

Each region is a full copy of Round 2 for its continent. Only three things are global: the CDN, the closures table, and the weekly release that every region loads.

The pieces:

• Per region: Round 2's telemetry pipeline, MLD routing fleet, sessions and reroute waves, plus a transit engine (RAPTOR over that region's feeds) and a closure service.
• Standby graphs: each region keeps 3 warm servers (one per AZ) holding another region's graph: EMEA's in us-east-1; the Americas' and APAC's in eu-west-1 (R3.8).
• Map data: conflation and release building run in one region; releases (graphs, tiles, packs) are replicated to all three regions' S3 buckets and served through CloudFront.
• Telemetry stays in its region. Pings are processed where they arrive; only aggregated speeds would ever leave.

Trace 1: a cross-continent route (Berlin to Beijing)

Synthesizing vector architecture diagram...

Two round trips across regions, for a route that takes days to drive.

Trace 2: an offline route. The phone in airplane mode holds the four cells covering greater London (release r2026-09-20, verified). The user asks for a route from Camden to Greenwich. The app snaps both points in the local search index, runs bidirectional A* on the merged cell graph with ETAs from the pack's historical profiles for the current time slot, and shows the route. It marks the ETA "offline, no live traffic". When signal returns, it fetches current closures for its cells and, if the route crosses one, recomputes locally or asks the server.

Trace 3: a closure broadcast. The sequence in step 3.5: the closure is written once in eu-west-1, applied to EMEA routing in about a second, affected sessions are rerouted nearest-first, other regions get it in about a second more, the overlay tiles show it within about a minute, and offline phones on their next connection.

R3.6 Numbers and Cost

Graph size and memory per region (graph sizes from GraphHopper's 2022 figures of 415M edges for the planet, 150M in Europe and 86M in North America; the rest of the split is our assumption. Memory per edge scaled from Round 2's 13.2 GB of shared structures for 86M edges, plus four weight sets: two for driving, one each for walking and cycling.)

Each region fits a c7g.8xlarge (64 GiB, 32 vCPUs) with room to spare.

Load per region

The Kinesis quota: the default is 20,000 shards per account in us-east-1, eu-west-1 and us-west-2, and 1,000 or 6,000 in other regions (we check ap-southeast-1's value in Service Quotas). ap-southeast-1 needs about 315 shards for the two streams (180 raw + about 135 observations), so it fits, but we confirm it and raise the standby regions' quotas (instances, shards) before launch.

Routing fleets (12 ms of CPU per request in EMEA for its bigger graph, 11 ms elsewhere, estimates; 60% target; 26 of 32 vCPUs for queries; enough servers after losing an AZ)

Tiles, offline packs and the CDN. CloudFront bills data transfer by the region of the edge that serves the viewer, and computes volume tiers separately for each such region, so we price each region with its own tiers. Asia-Pacific prices are higher at every tier.

Offline downloads: assume 5M full cell downloads a month × ~140 MB = 700 TB, and 20M diff updates × ~25 MB = 500 TB, 1.2 PB in total.

APAC serves the smallest share of traffic and costs the most. The table simplifies: it prices the Americas at US rates and EMEA at European rates, although South America, Africa and the Middle East cost more, and it prices all of APAC at Southeast Asian rates, although Japan, Australia and India have their own. A real bill needs the per-country split. At this volume, a committed-use discount or private pricing is the first lever.

Tile storage per release. A published full-planet build of zoom 0–14 is about 264M tiles and 99 GB; with packs (about the same again) and graphs, a release is a few hundred GB, replicated to three regions and kept for the last 8 releases: a few TB, under $1,000 a month.

Monthly cost (on-demand list prices; EC2 in eu-west-1 about 7% and in ap-southeast-1 about 15% above us-east-1, from the c7g.4xlarge prices of $0.6202 and $0.6664 against $0.58 an hour; we apply the same uplift to each region's whole pipeline, a simplification)

Synthesizing vector architecture diagram...

Serving pictures of the map costs more than all the computing combined; the famous part, routing, is under a tenth.

Per route computation, the routing fleets and standbys cost about $2.3 per million (61,940 ÷ 26.6B computations a month), and the whole platform about $26.5 per million. The telemetry pipelines cost about $5.6 per billion pings (177,290 ÷ 31.5 trillion pings a month).

R3.7 Trade-Offs

How to split the graph

Offline freshness vs download size

Build vs buy

Closing the loop. Round 1 found the shape of the problem: static tiles on a CDN, a static graph in memory, and preprocessing that turns a country-wide search into a few hundred steps. Round 2 made the weights live: a telemetry pipeline, map matching, and a preprocessing technique that separates the graph's shape from its weights, with a proven 30-second path from a braking car to a new route. Round 3 made it planetary: continents in their own regions, modes as weight sets, timetables with their own router, offline packs, conflated data, and closures as a live overlay. Through all three rounds the same idea holds: precompute what is static, stream what changes, and combine them at query time.

R3.8 Failure Modes

R3.9 Runbook and Incident Response

Signals, per region OPS 8 · REL 6

Emergency closure procedure OPS 10

1. Create the closure in the owning region through the closure tool (which writes the global-table item with a condition that it doesn't exist yet, and applies it to the fleet).
2. Verify on a routing server that the edges carry infinite weight, and that a test route across them now avoids them.
3. Watch the reroute wave: sessions found, rerouted, notices delivered.
4. Check other regions received the item (replication lag).
5. Set valid_until to the expected reopening; extend it rather than let it lapse silently.

Routing fallback procedure

1. If deltas are invalid or customization keeps failing, pin the fleet to the historical weight set (a feature flag): routes stay correct, only less current.
2. If a new graph release is suspect, roll back to the previous release number, blue/green.
3. If a region is down, fail over its route traffic to the standby region and scale the standby out.

Go deeper: CLI playbook

Plain commands, one at a time. Replace names and IDs with real ones.

textCopy
# 1. Telemetry lag on a region's raw stream
aws cloudwatch get-metric-statistics --region eu-west-1 --namespace AWS/Kinesis --metric-name GetRecords.IteratorAgeMilliseconds --dimensions Name=StreamName,Value=telemetry-raw-euw1 --start-time 2026-09-28T10:00:00Z --end-time 2026-09-28T11:00:00Z --period 60 --statistics Maximum

# 2. The raw stream's shard count and status
aws kinesis describe-stream-summary --region eu-west-1 --stream-name telemetry-raw-euw1

# 3. Tile cache hit rate (CloudFront metrics live in us-east-1; this one needs additional metrics turned on)
aws cloudwatch get-metric-statistics --region us-east-1 --namespace AWS/CloudFront --metric-name CacheHitRate --dimensions Name=DistributionId,Value=E2EXAMPLE1 Name=Region,Value=Global --start-time 2026-09-28T10:00:00Z --end-time 2026-09-28T11:00:00Z --period 300 --statistics Average

# 4. Create a closure only if it doesn't exist yet
aws dynamodb put-item --region eu-west-1 --table-name road-closures --item file://cl_88210.json --condition-expression "attribute_not_exists(closure_id)"

# 5. Roll apps back to the previous tile release
aws s3 cp s3://maps-releases-use1/styles/r2026-09-13/style.json s3://maps-public-use1/v1/style.json --cache-control "max-age=60"
aws cloudfront create-invalidation --distribution-id E2EXAMPLE1 --paths "/v1/style.json"

# 6. Scale a standby routing group during a regional failover
aws autoscaling set-desired-capacity --region us-east-1 --auto-scaling-group-name routing-standby-emea --desired-capacity 21

R3.10 Pillar Check

R3.11 Round 3 Rubric and Follow-Ups

What an architect (L7) answer adds over L6

• Partitions the graph by geography because queries stay inside geography, and explains how the multi-level structure stitches the rare cross-partition route.
• Treats modes as weight sets on one structure, and transit as a different problem with a timetable algorithm.
• Designs offline as versioned, checksummed, expiring packs with diffs, and keeps live data out of them.
• Replaces last-write-wins with provenance, confidence and review by risk, ending in validated releases.
• Separates urgent overlays (closures) from slow releases, with one writer per closure and clocks that aren't the database's.
• Plans the regional failure honestly: which region can serve which continent, at what capacity, after how long.
• Decides build vs buy with numbers per scale, including team cost and data rights.

Follow-up questions

1. "Why not put the whole planet on 128 GiB servers everywhere and skip the stitching?" Answer: it would fit, at about 82 GB. But every server in every region would customize the whole planet every 10 seconds, for traffic on continents its users never drive on; one bad delta anywhere would reach every server; and we'd still want the servers near users. The stitch costs two round trips on under 0.1% of requests. If cross-continent demand grew, a middle ground is to hold neighboring continents' graphs as well, with historical weights only.

2. "A driver goes online halfway through an offline route, and the server's route disagrees." Answer: the server's route is built on the current release with live weights; the phone's on an older pack with historical weights. When online, the app asks the server and, if the new route saves at least our reroute threshold (2 minutes and 10%), offers it; otherwise it keeps the current one. Routes carry their map_release, so a mismatch is explainable in support logs.

3. "A country requires that location data from its citizens stays in the country." Answer: that's a legal question first; we keep the answer general until counsel confirms what's required. Architecturally, telemetry already stays in the region where it's processed, so the change is to add an ingest and processing pipeline in a region inside that country (if AWS has one) and route that country's pings there by the phone's region setting, publishing only aggregated speeds outward.

Interview gotchas from this round

---

Loop Closer: Interview Strategy for All Three Rounds

How to Run Each 60-Minute Round

For how to spend a single 45-minute round, see the 45-minute interview blueprint.

The Two Sentences That Matter Most

• Opening a round: "Before I design: how big is the road network, which modes, do weights change, and how fast must routes and traffic be?"
• When the scope is raised: "Here's what breaks. I'll fix anything that could give a wrong or illegal route first, then freshness, then cost."

And the one sentence specific to this system: "Precompute what is static, stream what changes, and combine them at query time: tiles on a CDN, a graph whose shape is preprocessed once, and weights that are customized every few seconds from an ordered stream."

Well-Architected Review Sheet

Rubric Across Levels