System Design Method

Every topic playbook applies this lens. Read it before any single design.

System design is a chain of decisions under constraint: what to ingest, what to store, what to compute, what to serve. Each stage cuts waste and keeps signal. The best design chooses well what to do, and does no more.

The shape of any system

Almost every nontrivial system has four capabilities.

Two support planes sit beside them. The metadata and policy plane holds rules, scheduling, dedup, config, and quotas. The observability and control plane holds metrics, debugging, replay, backfill, and allow and block lists.

The three pillars (Kleppmann, DDIA)

Score every design against reliability, scalability, and maintainability. They are the non-functional spine.

Reliability means the system works correctly under hardware failure, software bugs, and human error. Werner Vogels: "everything fails all the time". The tools are Nygard's stability patterns: timeouts, retries with exponential backoff, circuit breakers, bulkheads, idempotency. A reliable system assumes its dependencies fail and degrades on purpose.

Scalability means handling growth in load. Define load parameters first (QPS, payload size, fan-out, read/write ratio), then describe performance under that load (p50, p95, p99, throughput). Prefer horizontal scaling and partition by a key that avoids hot spots. A scalability claim is the answer to "if load grows by X, what is the plan".

Maintainability means operable, simple, evolvable. Ousterhout's A Philosophy of Software Design asks for deep modules: simple interfaces over significant implementation. Complexity accumulates in dependencies and obscurity. Observability belongs in the design from the start.

Numbers every engineer should know (Jeff Dean)

Use these for back-of-envelope math. They are orders of magnitude.

Always show the sizing math. If you cannot do it, you do not understand the scale yet.

QPS         = DAU x actions/day / 86400
peak QPS    = avg x (2 to 10)
storage     = records x bytes/record x replication x retention
bandwidth   = QPS x payload

The 13-stage method

A System Design Doc walks these stages, and the template mirrors them.

Trade-off discipline

Never present one option as obvious. Name the alternative, the axis, and the choice:

Chose X over Y because {axis} matters more here, given {constraint}.

A design with no stated trade-off hid one.

Build pragmatically

Use a proven engine (Lucene, Postgres, Kafka, a managed queue) for the layer full of treacherous detail, and spend your quarters on the pipeline and logic that are your edge. Reinvent only the part that is the product.

Consistency, time, and ordering

Lamport's Time, Clocks, and the Ordering of Events in a Distributed System (1978) is the root of distributed reasoning. A distributed system has no single global "now", so you reason about causal ordering instead of wall-clock ordering. This underlies eventual consistency and vector clocks, and it is why relying on timestamps is a trap (clock skew).

Helland's Life Beyond Distributed Transactions draws the practical conclusion. At scale you give up cross-entity ACID and design around independent, idempotent units that reconcile eventually.

CAP and PACELC

Under a network partition (P) you choose availability (A) or consistency (C): Brewer's CAP. PACELC adds that else (E), with no partition, you trade latency (L) against consistency (C). Most real designs are AP under partition and trade latency for consistency in normal operation. Say which corner you sit in and why, per operation rather than per system.

The canon

Cite these when they sharpen a point.

The harness connection

The system-architect agent is itself a harness (Böckeler/Fowler): guides are feedforward, sensors and evals are feedback, humans stay on the loop. A design needs the same split. Computational controls (tests, linters, schema checks) and inferential controls (semantic review) run together. See Harness Engineering and Evals.

References

This page mirrors System Design Method in the wiki. Edit it there.