System Design

Every component in a design exists because a requirement put it there, and every component costs something. Work the steps in order: each one ends on a completion criterion, and the next step builds on what it produced. The references are pattern catalogs; open the one a step points at when the design reaches that branch.

Steps

1. Requirements

• Functional: the 2–4 core actions users take (actor + verb + noun: "users upload files"). Name what is out of scope.
• Non-functional, each with a number: daily and peak-concurrent users, read:write ratio, data size and retention, latency target (p99), availability, file or payload size limits, and problem-specific constraints (fairness, anti-bot, resumable uploads, ordering).
• Consistency per data type: money, inventory, and uniqueness need strong consistency; likes, feeds, and catalogs tolerate staleness. Decide per module, sometimes per query.

When the user gives no numbers, ask for them; when they can't say, state assumptions and label them as such.

Done when every non-functional requirement carries a number or a labelled assumption, and each data type has a consistency stance.

2. Back-of-envelope

Compute only the numbers that drive a decision, and write the decision beside each one.