---
title: "A repeatable system-design and architecture interview method"
chapter: "28"
---

# A repeatable system-design and architecture interview method

A good design process moves from purpose and numbers to boundaries, data, interactions, failure, security, and evolution. Product names come after forces.

## Core ideas and patterns

| Idea | What it solves | Cost, limit, or warning |
|---|---|---|
| **Clarify scope** | Prevents solving a different system | Time-box questions and state assumptions |
| **Estimate workload** | Sizes traffic, storage, bandwidth, and growth | Order-of-magnitude is enough to expose constraints |
| **Define SLOs/invariants** | Turns quality into design drivers | Avoid percentages without user journey |
| **Context and APIs** | Defines actors and external contracts | Premature endpoints can freeze weak boundaries |
| **Data model** | Exposes identity, ownership, transactions, and queries | A schema is not the full consistency model |
| **Critical flow** | Explains the normal end-to-end path | Also model timeout, duplicate, and partial failure |
| **Scale and resilience** | Adapts the bottleneck and failure model | Do not add every pattern by default |
| **Security/operations** | Makes trust, telemetry, rollout, and recovery real | Often omitted under interview pressure |

## How to apply it

Use this sequence: outcome and non-goals; actors/context; workload estimates; invariants and quality scenarios; logical boundaries; APIs/events; data ownership and consistency; critical sequence; deployment/failure domains; capacity; resilience; security/privacy; observability; delivery/migration; risks and ADRs. Revisit numbers when the design changes.

## Evidence, not opinion

End with explicit trade-offs, bottleneck, cost drivers, unresolved risks, validation experiments, and what would trigger a different architecture. A strong answer is coherent, not a catalog dump.

## Small example

For a URL shortener, clarify redirect/read dominance, custom aliases, expiry, abuse, geographic latency, and availability. Estimate key volume and read rate before choosing partitioning, cache, and multi-region behavior.

## Feynman check

Explain the design to a new engineer without using the pattern names. State the
problem, the forces that conflict, the chosen boundary or mechanism, what can
fail, and the evidence that would prove the choice still works.