Request Flow

The Design Verification Walk

An architecture diagram is a claim; the request flow walk is its verification. Trace one concrete request through every hop, annotating what each component does and costs. Designs that survive this walk are real; designs that don’t were never designed.

The Full Path (read example: rider opens trip history)

 1. DNS          app.rideshare.com → LB IP
                 └─ cached on device; ~0ms normally, ~50ms cold (recursive lookup)

 2. TLS          device ↔ LB handshake
                 └─ resumed via session tickets; full handshake ~1 RTT (~30ms first time)

 3. CDN/edge     static assets served here; API passes through
                 └─ hit: ~10–40ms total for assets; miss adds origin fetch

 4. Load         picks healthy app node; L7 routing by path
    balancer     └─ sub-ms decision; connection reuse matters

 5. AuthN        JWT verified locally in app tier (no round-trip)
                 └─ µs — signature check; this is why tokens beat session lookups

 6. App logic    parse params → authorize → build query plan
                 └─ <1ms

 7. Cache        Redis GET feed:user:{id}
                 └─ HIT: ~1ms → jump to step 9   MISS: +1ms, continue

 8. Database     replica SELECT ... ORDER BY created_at DESC LIMIT 20
                 └─ indexed read ~2–10ms; THIS is the p99 risk leg

 9. Serialize    rows → JSON
                 └─ ~0.1ms typical payloads

 10. Response    back up the chain; client renders

Latency Budget Thinking

Assign each leg a budget; the sum must fit the SLO:

Leg	Budget	Notes
Network client↔edge	20–50 ms	Physics; only geography improves it
Edge + LB	1–5 ms	Engineering
App processing	2–5 ms	Engineering
Cache or DB	1–10 ms	Dominant variable — design attention lives here
Total p95 target	under 300 ms	From NFR sheet

The table exposes the truth that drives architecture: the data-access legs own the tail. Everything else is fixed cost.

Write Requests Differ

Same walk, trip-creation request:

 steps 1–6 identical
 7. skip cache (invalidations follow)
 8. PRIMARY insert (trip row) in transaction with match update
    └─ fsync + commit ~5–15ms; the durability bill
 9. async side-effects enqueued (receipt, notifications) ← NOT inline
 10. respond 201 immediately after commit — user waits only for durable core

The write lesson: separate must-be-synchronous work (durable record) from can-be-asynchronous work (receipts, emails) — queues exist because of this line.

What the Walk Surfaces

• Hidden round trips (auth lookups, feature-flag fetches) that double latency.
• Missing caches where identical queries repeat.
• Legs needing different failure handling (DB timeout ≠ CDN timeout).
• Fan-out amplification (one page triggering twelve internal calls).

Each finding is an interview deep-dive candidate.

Interview Framing

“We’ll trace a GET /history request” is a power move mid-interview — it validates the diagram and surfaces the bottleneck discussion naturally. Strong candidates annotate 2–3 latencies aloud, land on the dominant leg (“DB reads own our p99”), and pivot there. The walk converts static diagrams into demonstrated understanding.