« Track Overview

System Design Walkthroughs

Five full worked designs, each following the same eight-step method, each ending with a what changes at 10× section and the questions you will actually be asked.

The method

This role is interviewed and reviewed at architecture altitude, and the difference between a strong and a weak design conversation is almost never knowledge — it is order. Weak designs start with boxes. Strong ones start with constraints and arrive at boxes.

The order that works for this JD:

1. Constraints before components. Volume, latency target, data classification, residency, regulatory obligations, and who the tenants are. Half the design space is usually eliminated here — a restricted-data workload with an on-shore requirement may have exactly one admissible model deployment, and discovering that after drawing the architecture wastes twenty minutes.

2. The request path, layer by layer. Users & Channels → Control Plane → Agent Kernel ‖ Knowledge Foundation → Action Gateway → the estate. For each layer, state what it denies. A design where two layers deny nothing has two layers too many.

3. Compose the SLO. Multiply the chain (Phase 00). Say the number out loud before anyone asks. Then identify which dependencies can be made degradable, because that is where the nines come from.

4. Write the latency budget. Per stage, with timeouts smaller than allocations, parallel groups marked, and — the line that matters — headroom. The headroom is the fallback decision.

5. Identity, end to end. Trace one request's credential from the human's token to what is presented to the system of record. Name the exchange at each hop and what narrows.

6. Failure modes and blast radius. For each dependency: what breaks, who notices, how, and what the platform does instead. Then the degradation ladder, in order, with the explicit statement that no control is on it.

7. Evidence. What artifact does each component emit, what join key links them, and what would you hand an examiner. In a regulated design this is not an appendix — raising it unprompted is one of the strongest signals available.

8. What you would build first, and what you would defer. A design with no sequencing is a wish list.

The five designs

They are written to be read in order — 01 sets the constraints, budgets and vocabulary the other four assume — but each stands alone if you are preparing for a specific conversation.

The numbers that recur across all five, so they are worth carrying: a 3,000 ms p95 interactive budget of which the model gets 800 ms and retrieval 350 ms; a naive serial composition of 98.96% that three named changes lift to 99.65%; ≥ 2 independent denials required for any irreversible action; 6 reproducibility pins; and a 60-second, audience-bound, single-resource credential at the estate.

The standing red flags

Assembled from every phase's STAFF-NOTES.md. Any one of these should stop a design review:

1. An SLO stated without the composition that produces it.
2. A dependency described as "highly available" with no number and no source.
3. A fallback with no latency budget, or a timeout larger than the remaining budget.
4. A retry policy that does not mention idempotency or the side-effect class.
5. Session state in a worker's memory.
6. A tenant_id read from a request body.
7. Any cache key without the tenant as its first component.
8. A shared vector index with a post-hoc entitlement filter.
9. Multi-agent delegation with no depth limit and no cycle detection.
10. A delegation chain passed as a request field.
11. A caller-supplied callback URL with no allow-list.
12. A control-plane call on the synchronous request path with no caching and no stated posture.
13. "We'll add observability later."
14. A control with no evidence artifact.
15. A diagram with five layers and no statement of what each denies.

How to practise

Take a design from the table above, set a 45-minute timer, and produce: the constraint list, the layered path with denials, the composed SLO with arithmetic, the latency budget with headroom, the identity trace, the failure table, the degradation ladder, and the evidence list. Then run the fifteen red flags against your own design — the ones you hit are the ones you will be asked about.

The phase documents to read alongside each design are the PRINCIPAL-DEEP-DIVE.md files: they are written at exactly this altitude and each one ends with a "what changes at 10×" section, which is the follow-up question every architecture interviewer eventually asks.