beginnerintermediateadvanced

System Design · Section 1

System Design Fundamentals

Level: beginner
Read: 20 min
Concepts: 4

System design is the process of translating a stated requirement into architecture, components, data flows, APIs, storage choices, operational behavior and failure handling. This section sets the vocabulary and the mental frame everything after it assumes.

This section

Front End System Design Fundamentals (All In One Comprehensive Guide)Shivam Bhalla

What is true here

System design translates a requirement into architecture, data flow, APIs, storage and failure handling.
A functional requirement says what the system does; a non-functional one says how well, with a number.
A constraint is fixed and known; an assumption is a stated belief, not yet proven.
Architecture, detailed design, implementation and operations are four different altitudes of the same system.

What you will be able to do

Translate a one-line requirement into architecture, data flow, APIs, storage and failure handling
Sort a requirement sentence into functional vs non-functional, and constraint vs assumption
Turn a vague requirement ("fast", "reliable") into a measurable one with a number
Tell which altitude — architecture, detailed design, implementation, or operations — a design question is actually asking about

The frame

What system design is, and the vocabulary every later section assumes.

What system design actually is

corebeginner

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.

Think of it as

A requirement is a sentence. A system design is everything that sentence implies once you ask: who calls this, how often, what does it store, and what happens the moment one piece of it fails.

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?

What we're doing: Show that a one-line requirement is underspecified until it is translated into concrete design decisions.

requirement.txttext

Requirement: "Users can upload a profile photo."

Left untranslated, this answers none of:
  - Max file size? Allowed formats?
  - Stored where — database blob, or object storage?
  - What does the client see while the upload is in progress?
  - What happens if the upload succeeds but writing the DB row fails?

1: This is the entire requirement as stated. Nothing about it is wrong — it is just incomplete for building.
3: Every one of these questions has a real answer that changes the resulting architecture.
7: This is a failure-handling question, and spec/08’s standard is that a design must answer it explicitly, not by accident.

Why this works: A requirement in plain English hides dozens of decisions. System design is the deliberate act of making each of those decisions explicit — architecture, components, data flow, APIs, storage, operations, and failure handling — rather than letting the first implementation choose them by accident.

Treating the requirement as the design

Wrong

text

Design doc: "Users can upload a profile photo. We'll use S3."

(nothing else specified — file size limits, failure handling,
and the API contract are all decided ad hoc during implementation)

Better

text

Design doc:
  API: POST /users/{id}/photo (multipart, max 5 MB, jpg/png)
  Storage: S3 object + Postgres row holding its key
  Failure handling: DB write happens in a transaction after
    a successful S3 upload; a failed DB write triggers cleanup
    of the orphaned S3 object

What you see: Two engineers implement the same one-line requirement differently, and the failure behavior — what happens when the upload succeeds but the database write does not — is never decided by anyone, only discovered in production.

Why: Skipping the translation step does not remove the decisions — it just defers them to whoever writes the code first, silently, with no review and no record of why.

What one requirement expands into

Requirement

one sentence

Architecture

components + boundaries

Data flow

who calls whom, with what

Operational behavior

failure handling, scaling

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

Core vocabulary: the terms every later section assumes

corebeginner

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.

Think of it as

Split every term into one of three buckets: what the system must DO (functional), how WELL it must do it (non-functional — latency, throughput, availability...), and what BOUNDS the design (constraints, assumptions, cost).

What we're doing: Sort one real requirement sentence into the vocabulary above, showing which words are doing which job.

requirement.txttext

"Support 10M requests/day at p95 latency under 300ms,
with 99.95% monthly availability, on our current
three-node Postgres cluster."

1: "10M requests/day" is capacity. "p95 latency under 300ms" is a non-functional requirement.
2: "99.95% monthly availability" is also non-functional — specifically the availability term.
3: "current three-node Postgres cluster" is a constraint: it is fixed, not a design choice up for discussion.

Why this works: Every later section of this roadmap uses these twelve words as if their meaning is settled. Sorting a real sentence into them once makes the distinction — especially functional vs non-functional, and constraint vs assumption — concrete rather than abstract.

Treating an assumption as a constraint

Wrong

text

"Traffic is evenly spread across 24 hours, so average
RPS is all we need to design for."

(this is an assumption, stated as if it were a fact — no
traffic data was actually checked)

Better

text

"We ASSUME traffic is evenly spread across 24 hours —
unverified. If wrong, peak RPS could be 3-5x average
for a consumer app with daytime usage. Flagging this
assumption for the requirements owner to confirm."

What you see: The system is built for average load, then falls over at 6pm every day because real traffic was never actually flat — the assumption was never checked or stated as a risk.

Why: A constraint is fixed and known — a deadline, a budget, an existing database. An assumption is a belief the designer is choosing to accept without proof. Treating the second as the first hides the risk instead of surfacing it.

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

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

Together

text

Requirement: "Support 10M requests/day at p95 < 300ms, 99.95% uptime."

  Functional:      handle a request and return a response
  Non-functional:  latency (< 300ms p95), availability (99.95%)
  Capacity:        10M requests/day -> ~116 req/s average
  Constraint:      must ship on the existing Postgres instance
  Assumption:      traffic is roughly even across 24 hours

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

Requirements and altitude

Two distinctions that keep a design conversation precise: what vs how well, and which altitude you are at.

Product requirements vs engineering requirements

standardbeginner

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.

Think of it as

Ask "can I write a pass/fail test for this sentence right now?" A functional requirement needs a scenario to test. A non-functional requirement already has a number in it.

text

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

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

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"

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

Together

text

Product requirement:
  "Users can search for a product."

Add the engineering requirement to make it testable:
  "Search returns results within 300ms at p95,
   for a catalog of up to 5M products."

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

Architecture vs detailed design vs implementation vs operations

standardbeginner

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).

Think of it as

Each level answers a different question. Architecture: what talks to what? Detailed design: how does each piece work internally? Implementation: what is the actual code? Operations: how does this stay alive at 3am?

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%

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

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

Together

text

Feature: "Users can upload a profile photo."

  Architecture:     API service -> object storage -> metadata DB
  Detailed design:  Photo table schema, upload state machine
                     (pending -> stored -> failed)
  Implementation:   the actual upload handler function
  Operations:       alert if upload failure rate > 1%,
                     runbook for "S3 unreachable"

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