beginnerintermediateadvanced

System Design · Final Senior-Level Standard

Three questions, three scopes

What changes with seniority is not the amount of knowledge but the question being asked — and the senior version ends with a filter, not another requirement

Junior"How do I implement this?" — correct when the decisions exist
Intermediate"What architecture and technology?" — correct as the last question
SeniorSeven inputs, and the simplest design that satisfies them
The filter"What number makes this necessary — are we at it?"

1."How do I implement this feature?"

The implementation question, and it is a good question — the code has to work, and someone has to write it. What defines it is scope: it takes the requirement, the architecture and the technology as given, and asks how to build within them. That is exactly right when those things really have been decided, and it is where most of the actual value in software gets produced. The failure mode is not asking it; it is asking only it, on a problem whose decisions have not been made. Then the implementation quietly makes them: a schema shape becomes the data model, a synchronous call becomes the coupling, a retry loop becomes the failure policy, and none of it was reviewed because none of it looked like a decision. The way to keep the question at its correct scope is to notice when an answer requires inventing something that was not specified — a status field nobody described, a timeout value nobody chose, a rule about what happens when the third-party call fails. Each of those is a decision escaping into code, and the useful move is to name it out loud rather than to pick one silently.

Key features

A correct question with a narrow scope: requirement, architecture and technology are taken as given
The failure is asking only it, on a problem whose decisions have not been made
Undecided things do not stay undecided — they get decided by whatever the implementation happened to do
The signal is inventing something unspecified: a status value, a timeout, a failure rule
Naming the invented decision out loud is the entire upgrade; you do not have to also answer it

What the implementation question covers, and what it assumes

What the implementation question covers, and what it assumes
Covered by the question	Assumed already decided
How the code is structured	Whether this is one service or two
Which library or framework call to use	Whether the operation is synchronous or queued
How the tests are written	What the system does when the dependency is down
How the data is read and written	What the schema is, and which invariants it enforces

Decisions that escape into code when nobody names them

Decisions that escape into code when nobody names them
What the implementer invents	The decision it silently makes
A status column with three values	The workflow's state machine, including which transitions are legal
A five-second timeout, because it felt right	The system's failure boundary and its worst-case request latency
A retry loop around a provider call	The duplication policy, if the call is not idempotent
Reading a related row inside a loop	The query count per request, and the point where the endpoint stops scaling

The question at its correct scope, and past it

In scope — a good question

The requirement is written and testable
The architecture and the store are chosen
The failure behaviour is specified
What is left is genuinely how to build it well

Past scope — decisions escaping into code

A status value nobody described
A timeout nobody chose
A retry around a call nobody said was safe to repeat
A query inside a loop nobody sized

Command

text

The upgrade is one sentence, not a promotion

  Instead of:
    "I'll add a status field with pending,
     done and error."

  Say:
    "The ticket does not say what happens
     when the provider call fails. I am going
     to need a state for it -- can we decide
     whether that is retryable or terminal
     before I pick one?"

  Same work. The difference is that a
  decision that was going to be made anyway
  is now made by someone who can see the
  whole workflow.

The implementation question is correct and narrow: it takes the requirement, the architecture and the technology as given. The failure is asking only it on a problem where those were never decided — then the implementation decides them, invisibly, because a schema shape and a timeout value do not look like design decisions. The signal is having to invent something unspecified, and the whole upgrade is naming it out loud rather than picking one silently.

2."What architecture and technology should I use?"

A real step up: it operates on shape rather than on code, and asks a question the implementation question cannot. It is also the most dangerous of the three, because its answers are the most plausible. "Microservices with Kafka and Postgres" sounds like a design, can be drawn on a whiteboard, and can be defended at length — entirely without reference to the requirement it was supposed to satisfy. That is what makes it hard to challenge: nothing in the answer is wrong, and nothing in it is derived. The tell is direction. A design that starts from architecture and technology has to bend the requirements to fit the choice, and the bending is invisible because it happens as a series of small reasonable-sounding accommodations. A design that starts from requirements produces the same words in the opposite order — the load and consistency needs and failure tolerance come first, and the technology falls out as the thing that satisfies them. So the upgrade is not to know more technologies. It is to answer this question last instead of first, and to be able to say which specific requirement each choice serves.

Key features

A real step up in scope: it operates on shape rather than on code
The most dangerous of the three, because a technology answer is plausible without being derived
The tell is direction — architecture-first bends requirements to fit; requirements-first lets technology fall out
The upgrade is not more technologies; it is answering this question last and tying each choice to a requirement
Every choice should survive the question "which requirement does this serve?" with a specific answer

The same words, in two directions

The same words, in two directions
Architecture first	Requirements first
"We will use Kafka."	"Two teams need the same event stream independently, and one needs to replay a week — that is a log, not a task queue."
"Microservices."	"Billing needs a different deploy cadence and on-call rotation than the rest, so it splits. Nothing else does yet."
"DynamoDB, for scale."	"Access is one key, we know every pattern, and the write rate exceeds one primary. Ad-hoc queries would have kept us on Postgres."
"Multi-region active-active."	"RPO is 5 minutes and RTO is 30, so a warm standby meets it. Active-active is not required, and it would add conflict resolution."

Three questions that expose an undirected answer

Three questions that expose an undirected answer
Ask	A derived answer sounds like	An undirected answer sounds like
Which requirement does this serve?	A named non-functional target with a number	"It is the standard choice"
What would change your mind?	A specific condition — a rate, a pattern, a team boundary	"Nothing really, it works for everything"
What is the simpler option you rejected?	One named alternative and why it loses here	Silence, or a general criticism of the simpler thing

Where each question operates

Requirements and constraints

What must be true: load, consistency, failure tolerance, cost, compliance. The senior question starts here.

Architecture and technology

Shape and components. The intermediate question starts here — which is why it has to bend the layer above to fit.

Implementation

Code, schema, tests. The junior question starts here, and inherits whatever the two layers above left unstated.

Command

text

Same question, answered last instead of first

  ASKED FIRST
    "What should we use?"
    -> Kafka, Kubernetes, Postgres
    -> requirements now get shaped to fit

  ASKED LAST
    "3,000 writes/sec, two independent
     consumers, one needs 7-day replay,
     ordering per customer."
    -> that is a partitioned log
    -> which is Kafka
    Same answer. Now it has a reason, and a
    condition under which it would change.

A real step up in scope, and the most dangerous of the three, because a technology answer is plausible without being derived — "microservices with Kafka" can be defended at length with no reference to any requirement. The tell is direction: architecture-first bends the requirements to fit the choice, in small accommodations nobody notices, while requirements-first produces the same words in the opposite order. The upgrade is not knowing more technologies; it is answering this question last, and being able to name the specific requirement each choice serves and the condition that would change it.

3.Seven inputs, and the simplest design that satisfies them

Seven inputs and one output. The inputs: requirements (what it must do), invariants (what must never be false), scale assumptions (the numbers, stated so they can be wrong), failure modes (what happens when each part breaks), consistency needs (per workflow, not globally), operational cost (money and human attention), and long-term trade-offs (what this makes harder later). The output is the last clause, and it is the load-bearing part: the simplest design that satisfies them. Without it, the seven inputs produce a thorough analysis and an elaborate design — which is the characteristic failure of senior engineers, not junior ones, because every input suggests a mechanism and adopting all of them is defensible at every step. Two of the seven deserve special attention. Invariants, because they are the things a system may never violate and they are almost never written down; a design that has not named them cannot be checked against them, and they are what actually decides where transactions and constraints belong. And scale assumptions stated as numbers rather than adjectives, because "high traffic" cannot be wrong and "2,000 requests per second at peak" can — and being wrong is what makes an assumption useful. This question does not replace the other two. It contains them: it ends in an architecture, which ends in an implementation.

Key features

Seven inputs: requirements · invariants · scale assumptions · failure modes · consistency needs · operational cost · long-term trade-offs
One output: the simplest design that satisfies them — this clause is what stops the analysis becoming an elaborate design
Over-engineering is the senior failure mode, because every input suggests a mechanism and each addition is individually defensible
Invariants are what a system may never violate, they are almost never written down, and they decide where constraints and transactions belong
State scale assumptions as numbers, because an adjective cannot be wrong and being wrong is what makes an assumption useful
It contains the other two questions rather than replacing them: it ends in an architecture, which ends in an implementation

The seven inputs, and what each one is actually asking

The seven inputs, and what each one is actually asking
Input	The question	What a good answer contains
Requirements	What must it do?	Functional behaviour plus non-functional targets with numbers
Invariants	What must never be false?	Sentences of the form "a seat is never held by two people" — checkable, and usually enforceable in a schema
Scale assumptions	How much of it is there?	Peak RPS, data per year, maximum fan-out — stated so they can be disproved
Failure modes	What happens when each part breaks?	One answer per dependency, plus what the user sees in each case
Consistency needs	Who must read their own write?	A decision per workflow, not one setting for the whole system
Operational cost	What does running it cost?	Money at current load, and how much human attention it needs at 3am
Long-term trade-offs	What does this make harder later?	The one-way doors: a shard key, a public API shape, a schema everyone depends on

The same design, before and after "simplest"

The same design, before and after "simplest"
Input suggested	The elaborate answer	The simplest answer that still satisfies it
Scale: 2,000 rps peak	Shard the database now	One primary with headroom; write down the rate at which sharding starts
Failure: provider outage	Circuit breaker, bulkhead, fallback provider, retry queue	Timeout and a degraded mode; add the breaker when an outage actually costs something
Consistency: stale reads reported	Move to strong consistency everywhere	Route the two workflows that need it to the primary; leave the rest on replicas
Trade-off: might need multi-region	Build active-active now	Keep state region-portable and revisit when a requirement names a second region

Three questions, three scopes — each contains the next

The senior question does not replace the other two; it ends in an architecture, which ends in an implementation.

Command

text

Seven in, one out

  IN
    requirements        what must it do
    invariants          what must never be false
    scale assumptions   the numbers, disprovable
    failure modes       per dependency
    consistency needs   per workflow
    operational cost    money and attention
    long-term trade-offs  the one-way doors

  OUT
    the SIMPLEST design that satisfies them

The last line is the hard part. Every input
above it argues for adding something.

Seven inputs — requirements, invariants, scale assumptions, failure modes, consistency needs, operational cost, long-term trade-offs — and one output: the simplest design that satisfies them. The last clause is what makes the question work, because every input argues for adding something and each addition is individually defensible; the filter is "what number makes this necessary, and are we at it". Write the invariants down as sentences that must never be false, state scale assumptions as numbers so they can be wrong, and record what you rejected and at what point it would be reconsidered.

Spotted a mistake on this page? Tell us.

Read Sheet