beginnerintermediateadvanced

System Design · Section 98

System Design Interview Process

Level: intermediate
Read: 14 min
Concepts: 2

The ten-step sequence — clarify requirements, estimate scale, define APIs, model data, propose an architecture, identify bottlenecks, deep dive, discuss failures and trade-offs, cover observability and security, summarise — is a dependency chain rather than a checklist, and the order is where most of its value sits. Requirements produce explicit non-goals, and scope excluded out loud is scope you are never asked to defend. Estimates turn those requirements into numbers, and the numbers are what make every later choice arguable instead of aesthetic. APIs precede the data model because entities and access patterns follow from the operations actually called. The architecture is short because the preceding steps constrained it. Identifying bottlenecks from the numbers is the step that selects the deep dive, so skipping it means deep-diving whichever component came to mind first — and depth is a fixed budget, so where it is spent is itself the answer. Failures, trade-offs, observability and security each get a named step because they are the areas most consistently omitted, and the summary states the design, the central trade-off and the first thing you would change with more time. Running the chain also enforces the second rule: name the need before the component. Access patterns — point lookup, range scan, relevance search, aggregate — decide a storage choice more than the shape of the data does, and stating them with numbers first is what allows anyone to review the choice rather than merely disagree with it. Requirement-first reasoning also survives being wrong, because a poor fit becomes a one-sentence substitution while a design built downward from a named technology has to be restarted.

This section

System Design Concepts Course and Interview PrepfreeCodeCamp.org

What is true here

Each step supplies an input the next needs, so jumping ahead means guessing at an input every later step inherits.
Estimates are what make later choices arguable; without them, component selection is taste.
Identifying bottlenecks selects the deep dive — a few minutes there decides where the session's depth is spent.
Some steps deserve one sentence and one deserves half the session; that allocation is itself the answer.
Say the need, then the component, then why it fits — that order is reviewable and survives a wrong choice.

What you will be able to do

Run the ten steps as a dependency chain and name what each one hands to the next
Use estimates to eliminate components from consideration before spending time on them
Rank bottlenecks from the numbers and choose the deep dive deliberately
State an access pattern with numbers before naming any technology that serves it

The sequence

Ten steps as a dependency chain, and why where you spend depth is itself the answer.

The ten-step sequence, and why the order is the content

coreintermediate

Ten steps, and the sequence carries most of the value because each one supplies an input the next needs. Clarifying requirements first fixes what the system must do and, more usefully, what it must not — scope you exclude out loud is scope you are not asked to defend later. Estimating scale converts those requirements into numbers, and those numbers are what make every following choice arguable rather than aesthetic: a read-to-write ratio decides caching, a peak request rate decides whether one database suffices, a storage growth rate decides whether sharding is on the table. Defining APIs pins down the actual operations, which is where vague requirements turn concrete and where missing ones surface. Modelling data follows the APIs because entities and access patterns come from what is actually called, not from a domain diagram drawn in the abstract. The high-level architecture is then a short set of components, and it is short precisely because the previous four steps constrained it. Identifying bottlenecks is where you name the parts that will break first, using the numbers from step two — and it is the step that determines what is worth a deep dive, so skipping it means deep-diving whatever came to mind. The deep dive spends real time on one or two critical paths rather than a shallow pass over everything. Failures and trade-offs make the design honest: what breaks, what degrades, and what you deliberately gave up. Observability and security are covered explicitly because they are the two things most consistently forgotten and most consistently asked about. And the summary restates the design, the key trade-off and the first thing you would change with more time — which is the part an interviewer remembers.

Think of it as

The order is a dependency chain, not a ritual. Requirements produce numbers; numbers produce an API and a data model; those produce an architecture; the architecture plus the numbers produce a bottleneck list; the bottleneck list chooses the deep dive. Jumping ahead means guessing at an input, and every later step inherits the guess. If you notice yourself unable to justify a choice, walk back up the chain — the missing justification is almost always an estimate you never made.

text

A workable time budget for a 45-minute session

  1-2   requirements and non-goals      5 min
  3     estimates                       5 min
  4-5   APIs and data model             7 min
  6     high-level architecture         6 min
  7     bottlenecks                     3 min
  8     deep dive (one or two paths)   12 min
  9     failures and trade-offs         4 min
  10    observability and security      2 min
  --    summary                         1 min

What we're doing: Run the first six steps on one prompt and watch the numbers eliminate options.

worked-sequence.txttext

Prompt: "Design a link-preview service. Given a
URL, return title, description and image."

1  REQUIREMENTS
   Goals:     fetch, parse, cache, serve previews
   Non-goals: rendering JavaScript pages,
              screenshotting, storing page bodies
   Constraint: previews may be up to 24h stale

2  ESTIMATES
   10M preview requests/day  -> ~115/s, ~600/s peak
   distinct URLs/day: 400k    -> ~5/s of fetching
   preview record ~2 KB       -> 800 MB/day, 290 GB/yr
   read:write ratio           -> 25:1

3  APIS
   GET /preview?url=...   -> 200 preview | 202 pending
   POST /preview/refresh  -> force a re-fetch

4  DATA MODEL
   previews(url_hash PK, title, description,
            image_url, fetched_at, state)
   access pattern: point lookup by url_hash. That
   is all. No secondary index is needed.

5  ARCHITECTURE
   API -> cache -> preview store
                -> fetch queue -> fetch workers
                                  -> outbound HTTP

6  BOTTLENECKS, from the numbers
   NOT the database: 5 writes/s, point lookups.
   NOT storage: 290 GB/year.
   IS the outbound fetch: third-party sites are
   slow and unreliable, and 5/s of fetching with
   multi-second latency needs real concurrency,
   timeouts and per-host rate limiting.
   -> the deep dive is the fetch path.

6: Stating non-goals early removes the largest source of scope creep in this problem. Rendering JavaScript changes the fetch path from an HTTP client into a browser fleet, which is a different system — and saying so is a stronger answer than silently assuming it away.
22: The data model here is deliberately boring, and the numbers are why. Once the access pattern is a point lookup at five writes per second, arguing about database choice is time spent where nothing is at risk.
32: This is the step that earns the sequence its keep. Without the estimates, the natural instinct is to deep-dive the database or the cache; with them, the only genuinely hard part is the one talking to the outside world.

Why this works: The estimates in step two did the work of steps five and six: they eliminated the database, the storage layer and the cache as concerns, and pointed at the one component whose behaviour is not under your control. That is the sequence functioning as designed — narrowing what deserves attention before any attention is spent.

Deep-diving before identifying bottlenecks

Wrong

text

# 20 minutes on sharding the preview database,
# replication topology and consistent hashing.
# The database takes 5 writes/s and does point
# lookups. Nothing in that discussion could have
# changed the outcome.

Better

text

# 3 minutes to rank what breaks first, using the
# numbers already on the board.
# Then 12 minutes on the fetch path: concurrency,
# per-host limits, timeouts, retries, and what
# happens when a target site hangs.

What you see: The session runs out of time having covered one component thoroughly and the actual risk not at all, and the design has no answer for the part most likely to fail in production.

Why: Depth is a fixed budget, so spending it is a choice about where. Ranking bottlenecks first — which takes a few minutes and uses numbers you already produced — is what makes that choice deliberate rather than a function of which component you happened to think about first.

The chain, with what each link hands to the next

1–2 · Requirements and estimates

Goals, non-goals, and the numbers every later choice is argued from.

3–4 · APIs and data model

Concrete operations first, then the entities and access patterns those operations imply.

5 · High-level architecture

A short set of components — short because the previous steps constrained it.

6–7 · Bottlenecks and deep dive

Name what breaks first using the numbers, then spend real time on one or two critical paths.

8–10 · Failures, operations, summary

What breaks and degrades, observability and security explicitly, then the design and its central trade-off.

What each step consumes and produces

What each step consumes and produces
#	Step	Consumes	Produces
1	Clarify requirements	The prompt	Goals, non-goals, constraints
2	Estimate scale	Requirements	Request rates, data volume, read/write ratio
3	Define APIs	Requirements	Concrete operations and their shapes
4	Model data	APIs, access patterns	Entities, keys, indexes
5	High-level architecture	Steps 1–4	Components and data flows
6	Identify bottlenecks	Architecture plus the numbers	A ranked list of what breaks first
7	Deep dive	The bottleneck list	A worked design for one or two critical paths
8	Failures and trade-offs	The deep dive	What breaks, what degrades, what was given up
9	Observability and security	The whole design	Signals, alerts, authz, data protection
10	Summarize	Everything	The design, the key trade-off, the next change

Remember: The order is the content: requirements produce non-goals, estimates produce the numbers every later choice is argued from, APIs produce the data model, and the architecture plus the numbers produce a ranked bottleneck list that selects the deep dive. Failures, trade-offs, observability and security get explicit steps because they are the ones most consistently skipped, and the summary names the design, the central trade-off and the first thing you would change. Spend time where the numbers say the risk is, not evenly.

The ordering rule

Requirements and access patterns before technologies, and why that order makes a choice reviewable.

Start with requirements and access patterns, not technologies

standardintermediate

Naming a technology early feels like progress and is usually a way of skipping the decision. "We will use Kafka and Cassandra" answers nothing on its own, because the reason a design is good is the fit between what the system must do and what a component provides — and until the requirements and access patterns are stated, there is nothing for the component to fit. Access patterns are the sharpest input here: how the data is read and written determines the storage choice far more than any property of the data itself. The same records want completely different systems depending on whether they are fetched one at a time by key, scanned in ranges by time, searched by relevance, or aggregated across everything. Starting from the pattern also lets you state a requirement a technology cannot satisfy, which is the most valuable thing a design discussion can produce early. The practical habit is to say what is needed before naming what provides it: "reads are point lookups by key at 40,000 per second, writes are 500 per second, and stale reads up to a second are acceptable" — then a component, then why it fits. That order also survives being wrong: if the component turns out to be a poor fit, the requirement is still correct and the substitution is one sentence, whereas a design built downward from a named technology has to be restarted.

Think of it as

Naming the tool before the job is choosing a hammer and then looking for something nail-shaped. In a design conversation it has a distinctive smell: the discussion moves to configuration and feature comparisons before anyone has said how much data there is or how it will be read. Notice that moment and step back one level — the missing sentence is always a requirement or an access pattern.

text

The order that makes a choice reviewable

  1. the need      "40k/s point lookups, 1s of
                    staleness acceptable"
  2. the component "an in-memory cache"
  3. the fit       "point lookups are what it is
                    fastest at, and the staleness
                    budget covers the TTL"

Someone who disagrees can now attack step 1 or
step 3. Starting at step 2 leaves nothing to
disagree with except taste.

Two orders of reasoning

Technology first

+Names a component before quantifying anything
+Requirements get bent to fit the choice already made
+A wrong choice means restarting the design
+Nothing to review except preference

Requirement first

−States the need and the access pattern, with numbers
−The component is chosen for fit, and the fit is stated
−A wrong choice is a one-sentence substitution
−Reviewable: the need or the fit can be argued with

The same records, four access patterns, four systems

The same records, four access patterns, four systems
Access pattern	Example question	Fits
Point lookup by key	"Give me order 8814"	Key-value or a row store with a primary key
Range scan by time	"Orders for this customer since March"	Row store with a composite index
Relevance search	"Orders mentioning 'refund request'"	Search engine
Aggregate over everything	"Revenue by month for four years"	Columnar warehouse

Two ways to say the same sentence

Two ways to say the same sentence
Technology-first	Requirement-first
"We will put Redis in front of it."	"Reads are 40k/s point lookups on a small, rarely-changing set, and a second of staleness is fine — so a cache fits, and Redis is a reasonable one."
"We will use Kafka."	"Several consumers need the same event stream, and we need to replay it after a bug — so a log-based broker fits."
"We will shard the database."	"Writes reach 40k/s against a single-primary ceiling of about 8k/s, so the write path has to be partitioned."

Remember: Name the need before the component. Access patterns — point lookup, range scan, relevance search, aggregate — decide the storage choice more than the data's shape does, so state them with numbers first. Say the requirement, then the component, then why it fits, because that order is reviewable and survives being wrong: a poor fit becomes a one-sentence substitution instead of a restart.