System design starts as an open-ended problem. You lead by defining scope, then narrowing the design.
Use these four steps to guide the design.
- Use cases
Define users, operations, constraints, and expected demand.
- High-level design
Identify the main responsibilities and request paths.
- Core components
Specify data models, interfaces, correctness, and failure behavior.
- Scale
Address measured or justified limits without discarding the earlier correctness requirements.
Scale the components that the requirements and bottlenecks actually justify.
How to read this model
A four-stage design review holder. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Gather requirements and scope the problem. Record assumptions.
Record:
- Who will use it?
- How will they use it?
- How many users are there?
- What does the system do?
- What are the inputs and outputs?
- How much data do we expect?
- How many requests per second?
- What is the read-to-write ratio?
Sketch the high-level design
Sketch the main components and connections. Justify each idea. Do not dive into details yet.
Define the core components
Dive into each core component. For a URL shortener, discuss:
- generating and storing a hash of the full URL (MD5, Base62, collisions)
- translating a hashed URL back (database lookup)
- SQL or NoSQL
- database schema
- API and object-oriented design
Scale the design
Find and fix bottlenecks. Ask: do you need a load balancer, horizontal scaling, caching, or sharding?
Back-of-the-envelope calculations
You may be asked to estimate by hand. Use:
- the powers of two table
- the latency numbers