beginnerintermediateadvanced

System Design · Requirements Clarification

Requirements Clarification

What to ask before drawing a single box, and the two boundaries every workflow needs drawn

Twelve questions firstbefore any component is drawn
Seven traffic shapesa system is usually several at once
Strong vs eventualdecided per field, not per system
Sync vs asyncdecided per workflow step

1.What to identify before drawing boxes

Before drawing a single box in a design, twelve questions should already have answers: who uses it, from what client, doing what, how much data, for how long, from where, how much traffic, and under what SLA, security and legal constraints.

Key features

Twelve questions, asked before any component is drawn
Read/write pattern alone can flip the right database choice
Retention period changes storage cost by orders of magnitude
Regional scope decides whether multi-region is even in scope

The twelve questions, and what each one decides

The twelve questions, and what each one decides
Question	Decides
Users	who the system ultimately serves
Clients	web, mobile, API, another service — shapes the API surface
Use cases	the actual workflows, not just "CRUD"
Read/write pattern	read-heavy vs write-heavy — flips the storage choice
Data volume	how much is stored, and how fast it grows
Retention period	how long data must be kept, and when it can be deleted
Regional scope	one region or many — flips replication strategy
Traffic shape	steady, bursty, seasonal — changes capacity planning
Peak traffic	the number the system must survive, not the average
SLAs	the availability and latency numbers the design is held to
Security requirements	auth, encryption, access boundaries needed
Regulatory constraints	data residency, industry compliance rules

Twelve questions, four themes

Who and how

Users

who is served

Clients

web, mobile, API

Use cases

real workflows

Shape and scale

Read/write pattern

which dominates

Data volume

how much, how fast

Retention

how long kept

Traffic

Regional scope

one region or many

Traffic shape

steady or bursty

Peak traffic

the number to survive

Bounds

SLAs

availability, latency targets

Security

auth, encryption, access

Regulatory

residency, compliance

Signature

users · clients · use cases · read/write · volume · retention · region · traffic · peak · SLA · security · regulatory

Twelve questions before any box is drawn: users, clients, use cases, read/write, volume, retention, region, traffic shape, peak, SLA, security, regulatory.

2.Naming the traffic shape

Seven words describe how load actually arrives at a system: read-heavy, write-heavy, bursty, interactive, batch-oriented, real-time, or event-driven — and each one points toward a different architecture.

Key features

Read-heavy favors caching; write-heavy favors throughput and partitioning
Bursty needs autoscaling tuned to the spike, not the average
Interactive needs low latency; batch-oriented trades latency for throughput
Event-driven and real-time both need a system that reacts, not just responds

The seven traffic shapes

The seven traffic shapes
Shape	Means	Points toward
Read-heavy	reads far outnumber writes	caching, read replicas
Write-heavy	writes far outnumber reads	write throughput, partitioning
Bursty	load spikes sharply at times	autoscaling tuned to the spike
Interactive	a human is waiting on the response	low latency over high throughput
Batch-oriented	work runs on a schedule, no one waits	throughput over latency
Real-time	results are needed within a tight window	streaming, not polling
Event-driven	work is triggered by events, not requests	queues, brokers, async processing

A social feed, named across every applicable shape

Read-heavy

read thousands of times, written once

Bursty

a viral post spikes reads 100x

Interactive

a human is waiting on it

Event-driven

a new post triggers fan-out

Command

text

A system can be more than one shape at once:
  a social feed  = read-heavy + bursty + interactive
  a log pipeline = write-heavy + batch-oriented
  a chat app     = interactive + real-time + event-driven

Seven shapes, usually several at once: read-heavy, write-heavy, bursty, interactive, batch-oriented, real-time, event-driven — each argues for a design choice.

3.Drawing the consistency boundary

Every piece of data needs one of two labels: strongly consistent (every read sees the latest write immediately) or eventually consistent (a read may briefly see stale data). Deciding this per field is the actual clarification step.

Sorting real data by the consistency it actually needs

Sorting real data by the consistency it actually needs
Data	Needs	Because
Account balance	strong	a stale read could allow overdrawing
Inventory count	strong	a stale read could oversell stock
Like count on a post	eventual	off by a few for a moment is harmless
Search index	eventual	a just-created post missing briefly is acceptable
"Last seen" timestamp	eventual	nothing depends on it being exact
Permission/role check	strong	a stale read could grant access that was just revoked

One question, asked per field: if this read is a few seconds stale, what breaks?

Strong — something breaks

Account balance — a stale read lets someone overdraw
Inventory count — a stale read oversells the stock
Permission or role check — a stale read grants access that was just revoked
Price on a product page — a stale read charges the wrong amount
The pattern: it gates a decision

Eventual — barely noticeable

Like count — off by a few for a moment harms nobody
Search index — a just-created post missing briefly is acceptable
"Last seen" timestamp — nothing depends on it being exact
"Recently viewed" list — a stale list is harmless
The pattern: it is displayed, not decided on

Command

text

Strongly consistent:   account balance, inventory count,
                        anything that gates a decision
Eventually consistent: like counts, view counts,
                        "last seen" timestamps, search index

Decide consistency per field, not per system — "a stale read here breaks something" means strong; "a stale read here is barely noticeable" means eventual.

4.Drawing the synchronous boundary

Every workflow step needs a decision: must it finish before the response goes back (synchronous), or can it happen afterward, off the request path (asynchronous)? Confusing the two is why "fast" APIs quietly do too much work inline.

Sorting a real workflow into synchronous vs asynchronous steps

Sorting a real workflow into synchronous vs asynchronous steps
Step	Boundary	Because
Validate the order	synchronous	the caller needs to know if it failed
Charge the payment	synchronous	the caller needs the charge result
Send a confirmation email	asynchronous	the order succeeds whether or not the email sends immediately
Generate an invoice PDF	asynchronous	can finish seconds after the response
Update the recommendation model	asynchronous	nothing about this request depends on it

Place an order — everything above the response, and everything after it

caller needsthis resultcaller needsthis resultqueuedqueuedqueued

POST /orders

Validate the order

The caller needs to know if it failed

Charge the payment

The caller needs the charge result

Update the inventory count

Must reflect this order immediately

201 Created

The boundary. Everything below is off the request path

Send the confirmation email

Generate the invoice PDF

Award loyalty points

Command

text

Synchronous:   validate input, charge a payment,
               anything the caller needs the RESULT of
Asynchronous:  send a confirmation email, update a
               search index, generate a thumbnail

A step is synchronous only if the caller needs its result to know the request succeeded — everything else belongs off the request path, queued for later.

Spotted a mistake on this page? Tell us.

Read Sheet