beginnerintermediateadvanced

System Design · Fundamentals

System Design Fundamentals

What system design is, the vocabulary it assumes, and the four altitudes of one system

Requirement → architecturedesign is the translation step
Functional vs non-functionalwhat it does vs how well
Four altitudesarchitecture, design, code, operations
A number makes it testable"fast" is not a requirement

1.What system design actually is

System design is the process of turning a stated requirement into an architecture: which components exist, how data moves between them, what APIs and storage they use, and how the whole thing behaves when something goes wrong.

Key features

Input: a requirement. Output: architecture, components, data flow
Covers APIs, storage choices, and operational behavior too
Failure handling is part of the design, not an afterthought
The same requirement can translate into several valid designs

What one requirement expands into

translatedintowiredtogether bymust survive

Requirement

one sentence

Architecture

components + boundaries

Data flow

who calls whom, with what

Operational behavior

failure handling, scaling

Command

text

Requirement:
  "Users can upload a profile photo."

Translates into:
  - API: POST /users/{id}/photo, multipart upload
  - Storage: object storage for the file, a DB row for its URL
  - Data flow: client -> API -> object storage -> DB write
  - Failure handling: what happens if the upload succeeds but the DB write fails?

System design translates a requirement into architecture, data flow, APIs, storage and failure handling — a box diagram alone is not a design.

2.Core vocabulary: the terms every later section assumes

Twelve words that recur through every system design conversation, each with a specific meaning: what the system must do, how well it must do it, what limits it, what it must never lose, and what it costs.

Key features

Functional = features. Non-functional = quality attributes
Constraints are fixed; assumptions are stated, not proven
Durability: data survives. Availability: the service responds
Consistency and cost cut across every other term here

The twelve core terms

The twelve core terms
Term	Answers
Functional requirement	what must the system do
Non-functional requirement	how well must it do it
Constraint	a fixed limit — budget, deadline, existing tech
Assumption	a stated belief not yet verified
Capacity	how much traffic/data/load to design for
Latency	time for one operation to complete
Throughput	operations completed per unit time
Availability	% of time the service responds correctly
Consistency	do all readers see the same data at once
Durability	does written data survive failures
Security	is access and data protected as intended
Maintainability	how cheaply the system can be changed
Cost	what the design costs to build and run

Three buckets every term falls into

What it must DO

Functional requirement

a feature the system must have

How WELL it must do it

Latency

time for one operation

Throughput

operations per unit time

Availability

% of time it responds

Consistency

do all readers agree

Durability

does data survive

What BOUNDS the design

Constraint

a fixed, known limit

Assumption

stated, not proven

Cost

what it costs to build and run

Signature

functional / non-functional / constraint / assumption / capacity / latency / ...

Functional = what it does; non-functional = how well. Constraints are fixed and known; assumptions are stated, not proven.

3.Product requirements vs engineering requirements

A product requirement says what a feature does. An engineering requirement says how well it must do it — and only the second one can be tested with a number.

Turning vague requirements into measurable ones

Turning vague requirements into measurable ones
Vague (functional only)	Measurable (adds non-functional)
Users can upload files	Upload completes within 2s at p99 for files under 10MB
The system should be fast	p95 API latency under 300ms
The system should be reliable	99.95% monthly availability
Data should not be lost	RPO of 5 minutes, RTO of 30 minutes

Same feature, two kinds of requirement

Functional

Describes a feature or workflow
Written from the user's point of view
No number needed to state it
Example: "users can upload files"

Non-functional

Describes a quality of that feature
Written as a measurable target
Needs a number to mean anything
Example: "p99 upload time under 2s"

Command

text

Functional (product):
  "Users can upload files."

Non-functional (engineering):
  "Uploads complete within 2 seconds at p99 for files under 10MB."

A requirement without a number cannot fail a test — pair every functional requirement with the non-functional one that makes it measurable.

4.Architecture vs detailed design vs implementation vs operations

Four altitudes for looking at the same system: architecture (components and boundaries), detailed design (schemas, state machines), implementation (the actual code), and operations (how it stays alive day to day).

What each level actually decides

What each level actually decides
Level	Decides	Example artifact
Architecture	which services exist, how they talk	a component diagram
Detailed design	internal structure of one component	a class diagram, a DB schema
Implementation	the literal code	a pull request
Operations	how it behaves once running	a dashboard, a runbook

Four altitudes, coarsest to finest

Architecture

components, services, network boundaries, major data flows

Detailed design

classes, schemas, state machines, internal APIs

Implementation

the actual code that runs

Operations

deploys, monitoring, on-call, incident response

Command

text

Architecture:     API service -> object storage -> metadata DB
Detailed design:  Photo table schema, upload state machine
Implementation:   the actual upload handler function
Operations:       alert if upload failure rate > 1%

Architecture decides what talks to what; detailed design decides how one piece works inside; implementation is the code; operations keeps it alive.

Spotted a mistake on this page? Tell us.

Read Sheet