System Design Interview · 30-Minute Field Guide

The order to remember.

01Clarify02Estimate03Draw04APIs05Data06Walk through07Go deep08Break it09Secure it10Summarize

Clarify the problem.

Minutes 0–5

Goal: Know what you are building before choosing technology.

Start by saying

“Let me restate the problem. We are building ___ for ___ so they can ___.”

Who uses it?

Regular users
Administrators
Human reviewers
Other systems
Background jobs

What do they do?

Create or upload
Read or search
Update or delete
Receive notifications
Review or approve

What is in version one?

“Which three or four features should I focus on?”

Say what you will not design: payments, login, mobile apps, advanced reports, or internal tools.

How big?

Daily users
Actions per user
Busy-hour multiplier
Expected growth
Records or files

How fast and reliable?

Which actions must feel immediate?
Which can run later?
May acknowledged data be lost?
Must another region take over?

How fresh?

“Must users see an update immediately, or is a short delay okay?”

This choice changes how much coordination your system needs.

What if the answer is wrong?

Is a missed result worse than a wrong one?
Can we reverse the decision?
Must a person approve it?

Is the data sensitive?

Personal, medical, or financial?
Keep customers separate?
Need an audit history?
Must data stay in one country?

What else must we call?

Payment or email provider
GitHub
Hospital or government system
AI model provider

∑

Do only useful math.

Still inside minutes 0–5

Rule: State an assumption, show the formula, round the answer, then say what it changes.

requests/sec = daily users × actions/day ÷ 86,400

Sizes the API and database.

peak requests/sec = average × 3 to 10

Capacity must handle the busy period.

read traffic = total traffic × read %

Heavy reads may benefit from a cache or read copies.

write traffic = total traffic × write %

Heavy writes may force data splitting.

storage = items × bytes/item × retention × copies

Include indexes and backups.

bandwidth = requests/sec × bytes/request

Large uploads may make the network the limit.

work in progress = jobs/sec × seconds/job

Estimates workers and open connections.

review hours = cases × review rate × min/case ÷ 60

People may be the real limit.

After the math, say

“This tells me ___. Therefore, I would ___.”

Finish this step

“I’ll focus on ___. Peak traffic is about ___. Writes must ___. ___ may be slightly delayed. I’ll leave ___ outside the scope.”

Draw the big picture.

Minutes 5–12

Goal: Use a few large boxes. Add a box only when it solves a requirement.

Web or mobile client

Load balancer / API gateway

Application

Main database

Work queue

Workers

File / search storage

1. Users and outside systems

Draw who starts work and the providers your system calls.

2. Entry point

Receive the request, check identity, apply limits, and route it.

3. Application

Start with one application. Split a responsibility only if it must scale, deploy, or fail separately.

4. Main database

Store the information your system considers correct: users, orders, cases, payments, decisions, status.

5. File storage

Use for images, videos, documents, backups, and large generated results.

6. Queue + workers

Use for slow work: processing, email, AI calls, reports, and slow providers.

7. Cache

Add only for repeated reads. Name the key, lifetime, stale behavior, and fallback.

8. Search storage

Add only when database queries cannot handle full text, complex filters, similarity, or location.

9. Outside services

Show timeouts, safe retries, and provider limits.

Quick architecture choices

Choose the simpler option until a requirement forces the other
Choice	Use it when	Cost
One application	Parts can scale and release together	Less freedom later
Separate services	Parts must scale, release, or fail alone	More network and operational work
Direct call	The work is quick and the user needs the result now	Caller waits; failures spread
Queue	The work is slow or can finish later	Delayed result; duplicates are possible
Redis cache	Many requests read the same data	May be stale; must be rebuildable

Walk through one normal request

“The client sends a request. The API checks access. The application validates it and saves the official record. Slow work enters a queue. A worker processes it, saves the result, and the client reads the new status.”

Design the main APIs.

Minutes 12–15

Goal: Show how people and systems use your design.

Start from user actions

POST /submissions
GET  /submissions/{id}
POST /submissions/{id}/complete
GET  /cases/{id}
POST /review-tasks/{id}/claim
POST /decisions

For each important API

Who may call it?
What does it receive?
What does it return?
Does it finish now or later?
Can the caller safely try again?
What errors can occur?

Large lists

Add pagination. Return a cursor that points to the next page.

Important creates

Accept a unique retry key so a repeated request does not create two payments, orders, or decisions.

Competing updates

Require the record version: “Update only if this case is still version 7.”

Response choice

Should the API finish the work now?
Style	Best when	Trade-off
Return result	Work is fast and predictable	Request stays open
Return job ID	Work is slow or failure-prone	Client must check status

Define the data.

Minutes 15–18

Goal: Explain what the system must remember and how it will read it.

Main records

User · Submission · Document · Case · Review task · Decision

Important fields

ID · customer ID · current state · version · created time · updated time · relationships

Common reads

Case by ID · pending tasks for a reviewer · documents in a submission · evidence behind a decision

Common updates

Finish upload · send case to review · claim task · publish decision

Choose storage from those reads and updates

“These records have clear relationships and important updates, so I would begin with a relational database.”

Separate the official data from useful copies

Official state

→

Main database

Searchable copy

→

Search storage

Temporary popular copy

→

Cache

Delayed reporting copy

→

Analytics storage

Say which copies may be slightly old. If two copies disagree, name which one wins.

Quick database choices

Main database
Choice	Pick it when	Watch out for
PostgreSQL	Related records and safe updates	Scaling writes takes planning
DynamoDB	Huge traffic; known key lookups	Changing queries are harder
MongoDB	Records are flexible documents	Relationships become harder
Redis	Tiny, key-based data needs extreme speed	RAM cost, limited queries, careful durability

Searchable database
Choice	Pick it when	Watch out for
Postgres search	Search is simple	Limited ranking and typo handling
OpenSearch	Advanced text, filters, ranking	Another system; results may lag
PostGIS	Nearby or area search	Only solves location search
pgvector	AI similarity search at moderate scale	Measure before very large scale

Default: PostgreSQL holds the official data. Redis is usually a rebuildable cache. Add a separate search database only when PostgreSQL search is not enough.

Quick AI choices

Two definitions

An embedding is a list of numbers that represents meaning. A vector database finds items with similar embeddings; it does not replace the official database.

Vector database choices
Choice	Pick it when	Main cost
pgvector	PostgreSQL already exists; start simple	Shares resources with normal database work
Pinecone	Want a managed service with little operations work	Vendor dependency and recurring cost
Qdrant	Want focused open-source vector search	Another database to run and synchronize
Weaviate	Want objects, vectors, and AI integrations together	More concepts and moving parts
Milvus	Vector search is central and extremely large	More infrastructure and operational work
Redis	Already use Redis and need very low latency	Memory cost; not the official document store
OpenSearch	Need keywords, filters, and vectors together	Heavy if vector search is the only need

How to improve an AI answer
Choice	Pick it when	Watch out for
Prompt only	Task is simple and facts are already supplied	Less control and grounding
Retrieval (RAG)	Facts change or answers need citations	Bad retrieval produces bad context
Fine-tuning	Need repeated behavior, style, or format	Needs training data and release testing
Human review	A wrong answer has a high cost	Slower and limited by reviewer capacity

Model selection
Choice	Pick it when	Watch out for
One model	Start simple; one quality level is enough	May overpay for easy work
Model routing	Tasks need different cost, speed, or quality	Every route needs separate evaluation
Fallback model	Availability matters more than identical output	Behavior and quality can change

AI output handling
Choice	Pick it when	Watch out for
Save evidence	Need audit, debugging, or review	Storage and privacy cost
Cache output	Same safe input repeats often	Stale or sensitive answers may be reused
Generate again	Freshness matters and variation is acceptable	Higher cost and different answers

Strong default: Start without vectors. Add pgvector when meaning-based search clearly helps. Use retrieval for changing facts, fine-tuning for repeated behavior, and human approval when a wrong result is expensive.

Follow one request.

Minutes 18–21

Goal: Prove the design works from beginning to end.

1. Start

What user action or outside event begins the work?

2. Handle

Which component receives it and checks it?

3. Read

What existing data is needed?

4. Write

What official state changes?

5. Continue

What happens immediately? What happens later?

6. Fail

What happens if this step does not finish?

Show the state changes

Uploading→Processing→Needs review→Approved or rejected

Go deep on one hard part.

Minutes 21–25

Goal: Show what makes this system different from a basic web app.

Use the same four-part story every time

State the problem.
Give a real example.
Explain the solution.
Explain what the solution costs or makes harder.

Possible hard parts

Prevent duplicate payments
Order messages
Process huge files
Find nearby places

More hard parts

Keep search permissions correct
Run long jobs safely
Handle two editors
Show evidence behind an AI answer

What to say

“The hard part is ___. For example, ___. I would solve it by ___. The trade-off is ___.”

Freshness choice

How quickly must copies agree?
Choice	Use it for	Cost
Immediate	Money, ownership, approvals	More waiting and coordination
Short delay	Search, analytics, notifications	Users may briefly see old data

Break the design.

Minutes 25–27

Goal: Show the system stays safe when normal assumptions fail.

Failure to test	What you must answer
The client sends the same request twice	How do we recognize it? Does the second call return the first result?
A worker crashes halfway through	Where was progress saved? Can another worker continue?
The queue sends the same job twice	Can processing twice change the result twice?
A provider finishes but the response times out	Can we look up the provider’s result before trying again?
Two users update one record	Does a version check reject the older update?
The database is unavailable	Do we fail, wait, or accept only work we can save safely?
One region fails	Who takes over? Could two regions both think they are in charge?
A job always fails	What is the retry limit? Where does a person see it?

Retry choice

Retries help only when the operation is safe to repeat
Choice	Use it when	Risk
Retry automatically	Failure is temporary and duplicates are blocked	Can overload a sick system
Stop and review	Result is unknown or failure repeats	Slower; needs a person

For every failure, answer

“How do we detect it? Is retrying safe? Where is progress saved? When do we stop retrying? When does a person step in?”

Secure it.

Minutes 27–28

Goal: Protect people, customers, and sensitive information.

Explain how users prove who they are.Explain how the server decides what they may do.Keep one customer from reading another customer’s data.Encrypt sensitive data while stored and while moving.Keep passwords and provider secrets in a secret store.Make removed access stop working quickly.Record important actions in an audit history.Keep sensitive values out of logs.

Important sentence

“The server finds the customer from the signed-in user. It never trusts a customer ID from the browser without checking it.”

Explain growth and operation.

Minutes 28–29

Goal: Say how the system grows, how you know it is healthy, and how you release safely.

Grow

Add API instances
Add workers
Add database read copies
Split data only when needed
Limit requests
Slow new work when queues grow

Measure

Request time and errors
Queue size and oldest job
Worker failures
Database load
Correct result rate
Cost and review time

Release

Test saved examples.
Run without changing real decisions.
Compare to the old system.
Enable a small group.
Increase traffic slowly.
Keep a rollback path.

Database growth choices

Scale in this order when measurements justify it
Choice	Helps with	Cost
Bigger server	Early read and write growth	Has a limit
Read copies	Heavy reads	May briefly return old data
Split data	Writes or data exceed one database	Harder queries and operations

Use only when the interviewer goes deeper

Extra cheat sheets.

The interview still follows the ten steps above. This bottom section is a lookup tool. Do not force every idea into every answer.

1. Make database reads faster

First name the read you need. Then choose the smallest change that makes that read fast enough.

Database access choices
Choice	Use it when	Main cost
Normal index	You filter or sort by known fields	More storage; writes become a little slower
Read copy	Reads are much heavier than writes	It may briefly show old data
Split the data	One database cannot hold or write everything	Queries across splits become harder
Saved result view	The same expensive result is requested often	The saved result must be refreshed

Say: “I would first add the index needed by this read. I would split the database only after one database is truly the limit.”

2. Put slow work in a queue

A queue lets the API accept work quickly and lets workers finish it later.

Message delivery choices
Choice	What it means	Use it when
At most once	A job may be lost, but it is not repeated	Losing the work is harmless
At least once	A job is not lost, but it may arrive twice	The worker can safely recognize repeats
One business result	Repeats may arrive, but only one result is saved	Use a stable job ID and a database uniqueness rule
Ordered	Jobs with the same key are handled in order	Order matters more than maximum speed

Good default: “I assume the queue may send a job more than once. Each job has a stable ID, and the database prevents a second business result.”

3. Use a cache without trusting it

A cache is a fast copy. The system should still be correct if the cache is empty or unavailable.

Common cache problems
Problem	Simple response	Why
Old value	Use an expiry time and remove changed entries	Limits how long old data survives
Missing value	Read the main database, then fill the cache	The main database still owns the truth
Many requests miss together	Let one request refill while others wait briefly	Protects the database from a sudden rush
One very popular key	Copy it locally or spread the load	One cache machine should not take all traffic
Cache is down	Fall back to the database and limit traffic	The cache improves speed, not correctness

Say: “Redis improves speed. Correctness does not depend on Redis being available.”

4. Choose how updates reach the client

Client update choices
Choice	Best for	Main cost
Polling	Simple, occasional status checks	Extra requests; updates arrive late
Long polling	Updates should feel quick but are uncommon	Connections stay open longer
Server-sent events	The server continuously sends updates to the browser	Mostly one-way
WebSocket	Frequent two-way messages, such as chat or live editing	More connection and recovery work
Webhook	One server tells another server that something happened	Must verify sender and handle repeats

5. State the recovery target

RTO

Recovery time objective: how long the service may take to come back.

RPO

Recovery point objective: how much recent data may be lost.

Example

“RTO is one hour. RPO is five minutes. We test restoring backups and switching regions.”

Approximate downtime per year

99.9%8h 46m

99.95%4h 23m

99.99%53m

99.999%5m

100%Not a realistic promise

6. Keep multi-step updates safe

When one action changes several things
Situation	Use	Plain meaning
Several records in one database	Database transaction	Save all changes or save none
Save data, then publish a message	Outbox record	Save the business change and “message to send” together
Several independent services	Steps with undo actions	If a later step fails, reverse earlier work where possible
Provider timed out	Look up by stable request ID	Find whether it already finished before trying again
Two people update one item	Expected version check	Reject an update based on an older copy

7. Choose an ID

ID choices
Choice	Pick it when	Main cost
Database number	One main database creates the records	Harder to create independently in many places
UUID	Many machines create records independently	Larger and less friendly to database indexes
Time-sortable ID	You want distributed IDs that roughly sort by time	Time order is not the same as cause-and-effect order
Dedicated ID service	Extreme distributed scale requires compact IDs	Another important service to operate

8. Protect the API

Validate the body, file size, and allowed values.Check identity and permission on the server.Limit requests by user, customer, and endpoint.Use cursor pagination for large or changing lists.Use a retry key for important create operations.Return a job ID when work will take a long time.Reject or slow new work when the system is overloaded.Do not expose secrets or internal errors in responses.

10. Requirement → likely component

Large files→Object storage

Slow work→Queue + workers

Repeated reads→Cache

Text ranking→OpenSearch

Meaning search→Vector search

Live two-way updates→WebSocket

Static global assets→CDN

Reports and analysis→Warehouse or object storage

Safe related updates→PostgreSQL

Huge known-key traffic→DynamoDB

These are starting points, not rules. Explain the requirement first, then name the component.