beginnerintermediateadvanced

System Design · Section 107

Priority Roadmap

Level: intermediate
Read: 22 min
Concepts: 3

Three tiers, ranked by how often a topic decides a design rather than by how hard it is to understand. Tier 1 is sixteen topics that appear in essentially every system — requirements, capacity estimation, APIs, data modeling, SQL, caching, queues, concurrency, transactions, consistency, availability, reliability, security, observability, scaling and trade-offs — and "master" here means two specific things: usable with no reference material, and correct about the failure mode rather than only the happy path. That second half is the demanding one. Anyone can describe cache-aside; mastering caching means knowing what four thousand concurrent misses on one expired hot key do, and having a per-key lock in the design before it happens. Tier 2 is thirteen topics you meet often but not always — Kafka and RabbitMQ, sharding, replicas, distributed transactions, sagas, the outbox, rate limiting, search, object storage, multi-tenancy, cloud, containers and disaster recovery — where the standard is to recognise when one applies, design with it at a whiteboard, and know its main failure mode, while configuration and API details may be looked up. The asymmetry is deliberate: failing to recognise that a workflow needs an outbox loses events silently, while forgetting the column types costs five minutes. Tier 2 is also where over-engineering starts, because each of these is genuinely powerful and adopting one without the requirement that justifies it imports its whole operational cost. Tier 3 is six specialized topics — consensus, multi-region active-active, advanced stream processing, custom storage engines, advanced scheduling and specialized distributed databases — where conceptual depth is the correct target, because for five of them the right move is to use an implementation that already exists and reason about the guarantee it gives you. Being deep in tier 3 while shallow in tier 1 is a recognisable pattern and an expensive one.

System Design overview

System Design for Beginners CoursefreeCodeCamp.org

What is true here

Ranked by how often a topic decides a design, not by difficulty — tier 1 is where nearly every real failure comes from.
Tier 1 standard: usable with no reference, and correct about the failure mode as well as the happy path.
Tier 2 standard: recognise, design, know the failure mode — configuration and API details may be looked up.
Tier 3 standard: choose a system that implements it and reason about its guarantee; you will not build it.
A tier-3 topic becomes tier 1 for you the day your job actually is that system.

What you will be able to do

Place your own current depth on each tier against a testable standard rather than a feeling
Tell a recognition gap (expensive) from a recall gap (five minutes of documentation)
Name the requirement that would justify each of the four tier-2 topics usually adopted too early
Spot the tier-3-deep, tier-1-shallow inversion in a design conversation, including your own

Master it

The sixteen that appear in every system, and what mastery is testable as.

Tier 1 — the sixteen to master

coreintermediate

Sixteen topics that appear in essentially every system you will ever build, which is what makes them tier 1: requirements, capacity estimation, APIs, data modeling, SQL, caching, queues, concurrency, transactions, consistency, availability, reliability, security, observability, scaling and trade-offs. "Master" needs a testable meaning or the tier is just an ordering. Here it means two things. First, you can use it without looking it up — not that you remember every option, but that you can produce a working design and the right vocabulary in a conversation, at a whiteboard, with no reference material. Second, and more demanding, you know the failure mode and not only the happy path. Anyone can describe a cache; mastering caching means knowing what a miss storm on a hot key does, and what a stale entry costs in the specific workflow you are caching. That second half is what separates tier 1 from having read about something. The list also has an internal order — requirements and capacity estimation come first because they produce the numbers every later decision is checked against, and trade-offs comes last because it is the skill of choosing between things you now understand well enough to compare. Getting all sixteen to that standard is a multi-year effort, and it is the difference between an engineer who can build a feature and one who can be handed a system.

Think of it as

The vocabulary of the language rather than the words you can look up. You do not stop to think about how to form a sentence; you think about what to say. These sixteen are the ones that have to reach that level, because they appear in every conversation and stopping to derive one of them means the design discussion never gets to the part that is actually hard.

text

Tier 1, in the order they get used

  BEFORE YOU BUILD
    requirements -> capacity estimation
    -> APIs -> data modeling

  THE DATA LAYER
    SQL · caching · queues · transactions

  CORRECTNESS UNDER LOAD
    concurrency · consistency
    availability · reliability

  RUNNING IT
    security · observability · scaling
    trade-offs

Master = usable with no reference material,
AND correct about the failure mode.

What we're doing: Tell "read about it" from "mastered it" on one topic, using a single follow-up question.

depth-check.txttext

TOPIC: CACHING

Q: "How would you cache the product page?"

A (read about it):
  "Cache-aside. Check Redis, fall back to
   the database, write the result back with
   a TTL."
  Correct. Complete for the happy path.

FOLLOW-UP: "The homepage product expires at
noon and you are serving 4,000 requests per
second. What happens at 12:00:00?"

A (read about it):
  "...they all miss and go to the database."
  Which is the right observation and the end
  of the answer.

A (mastered it):
  "That is a stampede -- 4,000 concurrent
   misses on one key, all executing the same
   query. Three ways to handle it, and I
   would use the first:
     1. A per-key lock: the first miss
        rebuilds, everyone else waits briefly
        or serves the stale value.
     2. Probabilistic early expiry: each
        reader has a small chance of
        refreshing before the TTL, so the
        rebuild is spread out.
     3. A background refresher for known hot
        keys, so they never expire on the
        read path at all.
   And I would add jitter to the TTL either
   way, so a batch of keys written together
   does not all expire in the same second."

WHAT THE FOLLOW-UP MEASURED

  Not knowledge of Redis. Whether the
  failure mode is part of what "caching"
  means to this person, or something they
  would discover in production.

  Every tier-1 topic has a question like
  this:
    queues       -> "the message is
                     delivered twice"
    transactions -> "the provider call
                     inside it times out"
    availability -> "one component is not
                     redundant"
    scaling      -> "what saturates first?"

  Knowing the happy path is the entry fee.

11: The follow-up supplies a number and a moment. That is what turns a general question into one that can only be answered by someone who has thought about the failure.
21: Three named options with a stated preference is the shape of a mastered answer: it shows the space was explored and a choice was made, rather than one remembered technique.
34: TTL jitter is the detail that only comes from having seen synchronised expiry happen. It is a one-line change that removes an entire class of periodic load spike.

Why this works: Tier 1 is defined by this second layer, not the first. Every one of the sixteen has a happy path that takes an afternoon to learn and a failure mode that takes a production incident or a deliberate study to internalise — and the failure mode is the part a design depends on.

Studying the list in the order it is written

Wrong

text

# Week 1: requirements
# Week 2: capacity estimation
# Week 3: APIs
# ...
# Sixteen topics learned in isolation, each
# to the happy-path level, with no system to
# check them against. Nothing sticks,
# because nothing failed.

Better

text

# Build one small system that needs six of
# them at once -- project 1 or 8 from the
# previous section.
# Then break it on purpose:
#   expire a hot key under load
#   deliver a message twice
#   kill a worker mid-transaction
# The failure modes are the curriculum.

What you see: A confident vocabulary with no depth behind it: every topic can be defined, none can be defended against a follow-up, and the first real design decision produces a technology choice rather than a mechanism.

Why: These sixteen interlock — caching only makes sense against a consistency requirement, queues only against a failure model — so learning each alone teaches the definition and not the interaction. Building something that needs several at once, then breaking it deliberately, produces the failure-mode knowledge the tier is actually defined by.

Tier 1 — sixteen topics, in the order they get used

Before you build

Requirements

Capacity estimation

produces the numbers everything else is checked against

APIs

Data modeling

The data layer

SQL

Caching

Queues

Transactions

Correctness under load

Concurrency

Consistency

Availability

Reliability

Running it

Security

Observability

Scaling

Trade-offs

last, because it compares the other fifteen

The sixteen, and the test that says you have it

The sixteen, and the test that says you have it
Group	Topic	You have it when you can…
Before you build	Requirements	Separate functional from non-functional and turn a vague ask into measurable targets
Before you build	Capacity estimation	Get from a business number to peak RPS, storage per year and connection count, out loud
Before you build	APIs	Design a resource model with pagination, versioning and a stable error contract
Before you build	Data modeling	Derive a schema from access patterns and express each invariant as a constraint
The data layer	SQL	Read a query plan and say why an index is or is not being used
The data layer	Caching	Name pattern, key, TTL and invalidation — and say what a miss storm on a hot key does
The data layer	Queues	Explain at-least-once delivery and design a consumer that survives it
The data layer	Transactions	Say what a transaction does and does not protect, and keep network calls out of one
Correctness under load	Concurrency	Spot a read-then-write race and replace it with a conditional update
Correctness under load	Consistency	Choose a model per workflow and explain what the user sees under each
Correctness under load	Availability	Convert a nines target into a downtime budget and find the hidden single point of failure
Correctness under load	Reliability	Distinguish "up" from "correct" and design for partial failure
Running it	Security	Place authentication, authorization and encryption at the right boundaries, per object
Running it	Observability	Define a symptom-based alert per user-visible promise, and trace a request across services
Running it	Scaling	Name the first component to saturate, at what load, and why
Running it	Trade-offs	State any decision as benefit, cost, alternative and reason

Two levels of knowing, on the same topic

Two levels of knowing, on the same topic
Topic	Read about it	Mastered it
Caching	Knows cache-aside, read-through, write-through	Knows what happens when a hot key expires and 4,000 requests miss at once — and has a per-key lock in the design
Queues	Knows producers, consumers and dead-letter queues	Assumes at-least-once by default and makes the consumer idempotent without being asked
Transactions	Knows ACID	Knows the transaction holds locks for the duration of anything inside it, so a provider call never goes in one
Availability	Knows "three nines"	Knows three nines is 43 minutes a month, and has checked whether one component makes it unreachable

Remember: Sixteen topics that appear in every system: requirements, capacity estimation, APIs, data modeling, SQL, caching, queues, concurrency, transactions, consistency, availability, reliability, security, observability, scaling, trade-offs. "Master" means two things — usable with no reference material, and correct about the failure mode, not just the happy path. The second half is the demanding one and the one designs actually depend on. Tier 1 is ranked by how often it decides a design, not by difficulty: these are where nearly every real failure comes from.

Know it well enough to design with

Thirteen topics you meet often, the standard for them, and the four usually adopted too early.

Tier 2 — strong working knowledge

standardintermediate

Thirteen topics you meet often but not always: Kafka and RabbitMQ, sharding, read replicas, distributed transactions, sagas, the transactional outbox, rate limiting, search, object storage, multi-tenancy, cloud services, Docker and Kubernetes, and disaster recovery. The standard here is lower than tier 1 and still specific. You must recognise when the topic applies, be able to design with it at a whiteboard, and know its main failure mode — but you may look up the configuration, the exact API and the operational details. So: you should be able to say that a workflow spanning two services needs a saga with compensating actions, sketch the steps and name what happens if a compensation fails, without remembering any particular framework's decorator syntax. The distinction that matters is recognition versus recall. Failing to recognise that you need an outbox produces a system that silently loses events; failing to recall the exact column types costs five minutes with the documentation. Tier 2 is also where most over-engineering originates, because each of these is genuinely powerful and adopting one without the requirement that justifies it imports its whole cost — Kafka brings partitions, consumer groups, rebalancing and lag monitoring whether or not you needed replay.

Think of it as

Tools you can pick up and use correctly, but do not carry. You know what each is for, what it does badly, and roughly what using it involves — and when you reach for one you expect to read the manual. What you never do is fail to notice that the job needs one.

text

Tier 2 — the standard, stated as a test

  Given a requirement, can you:
    1. name the tier-2 topic it needs?
    2. sketch the design on a whiteboard?
    3. say its main failure mode?
  Then you have strong working knowledge.

  Not required: config, API surface,
  operational runbooks. Look those up.

  The expensive failure is (1).
  Missing "this needs an outbox" loses
  events silently. Forgetting the column
  types costs five minutes.

The three tiers, ranked by how often each decides a design

Tier 1 — master (16 topics)

In every system. Usable with no reference, and correct about the failure mode.

Tier 2 — strong working knowledge (13 topics)

Often, not always. Recognise it applies, design with it, know its failure mode; look up the details.

Tier 3 — conceptual (6 topics)

Rare, or someone else's implementation. Know what problem it solves and when to reach for a system that has it.

The thirteen: what you must be able to do, and what you may look up

The thirteen: what you must be able to do, and what you may look up
Topic	Must be able to (no reference)	May look up
Kafka / RabbitMQ	Say which one a workload wants and why — replayable log versus task queue	Consumer group config, exchange bindings, retention settings
Sharding	Choose a shard key, and say what a cross-shard query costs	Rebalancing procedure, vendor-specific tooling
Read replicas	Decide per workflow which reads tolerate lag, and how much	Replication setup and failover commands
Distributed transactions	Explain why two-phase commit is usually avoided and what it costs	Coordinator protocol details
Sagas	Sketch the steps, the compensations, and what happens when a compensation fails	Framework or orchestrator syntax
Transactional outbox	Recognise the dual-write problem and place the outbox row in the right transaction	Relay implementation, CDC connector config
Rate limiting	Pick an algorithm and identity key, and make the check atomic	Exact script or library API
Search	Say when a database index is not enough, and keep the index derived	Analyzer and mapping syntax
Object storage	Keep bytes out of the app tier; scope signed URLs to one key and method	SDK calls, lifecycle rule syntax
Multi-tenancy	Choose an isolation model and enforce it on every path, not just queries	Row-level security policy syntax
Cloud	Choose managed versus self-hosted with a stated reason, and know the cost surface	Service names, quotas, console navigation
Docker / Kubernetes	Explain what containers change about deployment — and what they do not change about architecture	Manifest fields, operator specifics
Disaster recovery	State RPO and RTO first, then let them choose the strategy	Restore runbook steps

Four tier-2 topics that are usually adopted too early

Four tier-2 topics that are usually adopted too early
Topic	The requirement that justifies it	What it costs without one
Kafka	Replay, or multiple independent consumers of the same stream	Partitions, consumer groups, rebalances and lag monitoring to run a task queue
Sharding	One primary genuinely cannot hold the write rate or the data	Cross-shard queries, resharding, and a shard key you cannot change
Microservice-scale multi-tenancy	Customers with genuinely different isolation or compliance needs	Per-tenant migrations and connection pools for a product with fifty users
Kubernetes	Enough services and scaling variance for scheduling to be a real problem	A second system to operate, debug and upgrade, wrapped around three containers

Remember: Thirteen topics you meet often but not always. The standard is recognise, design, know the failure mode — configuration and API details may be looked up, because failing to recognise that a workflow needs an outbox loses events silently, while forgetting the column types costs five minutes. Tier 2 is also where over-engineering starts: each topic is genuinely powerful and adopting one without the requirement that justifies it imports its whole operational cost. Replicas before sharding, RabbitMQ for task queues, Kafka for replayable logs, and containers change deployment rather than architecture.

Understand it, do not build it

Six specialized topics where choosing well and reasoning about the guarantee is the whole deliverable.

Tier 3 — conceptual and specialized

standardadvanced

Six topics where understanding the idea is the goal and implementing it usually is not: consensus algorithms, multi-region active-active designs, advanced stream processing, custom storage engines, advanced scheduling, and specialized distributed databases. Conceptual is the right depth rather than a concession, because for five of the six the correct move in a real system is to use something that already implements it. You will not write Raft; you will choose etcd or a managed service and need to know what "a quorum of three" buys and what it costs in latency. You will not build a storage engine; you will need to know why a log-structured merge tree is fast at writes and pays for it at read time, so that you can predict how a database will behave under your workload. What you need is the vocabulary to choose well and to reason about a guarantee someone else implemented. The exception is multi-region active-active, which is conceptual for a different reason: it is not that you would use a library, it is that almost no system needs it, and the sections on multi-region systems and disaster recovery cover the decision. Being deep here while tier 1 is shallow is a recognisable pattern and a costly one, because tier-1 topics decide ten thousand times as many designs.

Think of it as

Knowing how an engine works without being a mechanic. It changes how you drive, what noises alarm you and which car you buy — and none of that requires being able to machine a piston. The knowledge earns its place by improving choices, not by enabling construction.

text

Tier 3 — the test is different

  Tier 1:  can you use it, with no reference?
  Tier 2:  can you recognise it and design
           with it?
  Tier 3:  can you choose a system that has
           it, and reason about the guarantee
           it gives you?

  You will not write Raft. You will pick
  etcd and need to know that a quorum of 3
  survives 1 failure, that 4 nodes survive
  the same 1, and that every write costs a
  round trip to a majority.

Tier 3 — six topics you reason about rather than build

Consensus algorithms

use etcd or a managed service; know what a quorum costs

Multi-region active-active

conflict resolution is a product question first

Advanced stream processing

event time ≠ processing time; late data is normal

Custom storage engines

B-tree vs LSM predicts your database's behaviour

Advanced scheduling

fairness and preemption are policies, and defaults are choices

Specialized distributed databases

each buys one property and charges elsewhere

The six, and what conceptual depth actually means for each

The six, and what conceptual depth actually means for each
Topic	Why conceptual is enough	The one thing to carry
Consensus algorithms	You will use etcd, ZooKeeper or a managed service, not implement Raft	A quorum needs a majority, so an even number of nodes buys nothing — and every write pays a round trip
Multi-region active-active	Almost no system needs it; the requirement is the decision	Two regions accepting writes means conflict resolution, which is a product question before it is a technical one
Advanced stream processing	Frameworks own windowing, state and checkpointing	Event time is not processing time, and late data is normal rather than exceptional
Custom storage engines	You choose a database; you do not write one	B-tree reads well and writes in place; LSM writes fast and pays at read and compaction time
Advanced scheduling	Kubernetes, cloud schedulers and job frameworks implement it	Fairness, priority and preemption are policies — defaults are a choice somebody already made for you
Specialized distributed databases	The value is choosing the right one for a workload	Each buys one property (global order, geo-distribution, time series) and charges for it somewhere else

The recognisable inversion

The recognisable inversion
Symptom	What it usually means
Can explain Raft; cannot state the service's peak RPS	Tier 3 studied, tier 1 assumed
Proposes active-active; has not written an RPO or RTO	The exotic answer arrived before the requirement
Compares LSM and B-tree in review; the schema enforces invariants in application code	Depth applied where it does not decide anything

Remember: Six topics where understanding is the goal and implementing is not — consensus, multi-region active-active, advanced stream processing, custom storage engines, advanced scheduling, and specialized distributed databases. For five of them you will choose an existing implementation, so the deliverable is vocabulary and the ability to reason about someone else's guarantee; multi-region active-active is conceptual because almost no system needs it. Being deep here while tier 1 is shallow is a costly and recognisable pattern — the tiers rank by how often something decides a design, so a tier-3 topic becomes tier 1 for you the day your job is that system.