System Design Interview Framework: A Repeatable 45-Minute Plan

Without a system design interview framework, you spend the clock on whatever comes to mind first. You start in the middle, go deep too early, and never reach the parts the interviewer wanted to hear.

Picture a common setup. A backend engineer who builds parcel tracking services at a logistics company sits a 45-minute mock round. The interviewer gives one line: design a shipment tracking service. The setup is made up, but the problem is real.

The candidate knows this problem from work, so they start fast. A database goes on the board, and 20 minutes go on table columns and indexes. At minute 38, there is still no path from a hub scan to a customer's phone.

Afterwards, the interviewer gives four pieces of feedback.

• You never asked how many parcels there were, how fresh the status must be, or who uses the service.
• You gave no numbers, so I could not tell whether one database was enough.
• Your deep dive was on the part I cared least about.
• You never named a trade-off, so I heard what you would build but not why.

None of that feedback is about knowledge. The candidate knows the material but has no plan. This guide is that plan, and the same mock runs through every section, done in order the second time.

A system design interview framework is a fixed order of steps, each with a time box, that you follow for any design question. It does not give you the answer. It gives you a route through the conversation.

First, the round itself. A system design interview asks you to design a large software system, such as a URL shortener or a chat app, while you talk it through with an interviewer. There is rarely one right answer.

Without a route, you jump between topics, and the interviewer cannot follow your thinking. With one, every step leaves something on the board that the next step builds on.

Think of a Bharatanatyam recital, the classical dance from Tamil Nadu. Its traditional order of pieces, the margam, is settled before the dancer walks on stage. Here is how the parts map.

• A warm-up piece such as the alarippu opens the recital. That is your requirements step: short, and it prepares both of you for what follows.
• The varnam is the longest piece, the centrepiece where technique shows. That is your deep dive, which gets the biggest share of the clock.
• The tillana usually closes the recital on pure rhythm. That is your two-minute wrap-up.
• Because the order is settled, the dancer's attention goes to rhythm and expression. Yours goes to the parcel scans, not to what comes next.

Where the picture breaks: a dancer rehearses the exact pieces in advance. You do not know the question, and the interviewer may stop you halfway and ask for a different piece.

The idea also matches how real teams design. Google's SRE workbook has a chapter on non-abstract large system design, a method of designing with real numbers of machines. It asks whether a design is possible, then whether you can do better.

Then it asks whether the design is feasible within real limits and resilient when parts fail. Its worked example starts, on purpose, with the whole application on one computer. The numbers and the failure cases show that cannot work, which points to the next design.

Spend about 15 minutes understanding the problem and 30 designing it. That is 5 minutes each on requirements, estimates and the API, then 10 on the big picture, 13 on the deep dive and 7 on failures and the wrap-up.

This split is our rule of thumb, not a published standard. Hello Interview's delivery framework, as of 19 October 2026, gives different timings. It suggests about 5 minutes for requirements, 5 for the API, 10 to 15 for the high-level design and about 10 for deep dives.

That framework also skips upfront estimates unless they change the design. The estimation section below explains where we differ and why.

This plan assumes about 45 minutes of actual design. Check your invite, because introductions and your own questions at the end take part of the slot. If you have less time, shrink the deep dive and the failures step first.

Here is the plan as a chain of steps. Read it from the first box to the last, and notice that the deep dive gets the biggest share of the clock.

The table below adds two columns that matter in practice. One says what you should have on the board by the end of each step. The other says what the interviewer is listening for while you do it.

Ask who uses the system, what it must do, how big it is, and how fast or fresh it must be. Then write the answers where the interviewer can see them.

Those answers split into two kinds. Functional requirements are what the system does, such as showing a parcel's latest status. Non-functional requirements are how well it does it, such as speed, uptime and cost.

In the second mock, the candidate asks five questions before drawing anything, and the interviewer answers each one.

• Who uses it? Customers checking a parcel, and hub staff whose handheld scanners send scan events.
• What must it do? Record every scan, and show the latest status and full history for any tracking number.
• What is out of scope? Route planning and payments, which the interviewer agrees to skip.
• How big is it? About 20 lakh (2 million) parcels a day, each scanned about 10 times on its journey.
• How fresh must status be? A scan should be visible to customers within one minute.

That last answer shapes the whole design. A one-minute window means scans can be saved in the background, through a queue, instead of making scanners wait for every database write.

Next, turn vague words into numbers. Instead of saying the page must be fast, say it should load in under 300 milliseconds for 99 percent of requests. Google's SRE book calls a target like this a service level objective, or SLO.

The same book prefers percentiles to averages for latency, which is how long one request takes. An average can hide a slow tail of requests. A 99th percentile of 300 milliseconds means at most 1 request in 100 is slower.

If you run out of questions, walk a short checklist. The AWS Well-Architected Framework names six pillars: operational excellence, security, reliability, performance efficiency, cost optimization and sustainability. You will not cover all six in five minutes, but the list stops you forgetting one completely.

You need just enough estimation to choose between designs: requests per second at average and peak, and storage over a year. Rough, rounded numbers said out loud are enough.

Estimation in interviews is often called back-of-the-envelope maths, meaning quick sums with round numbers. The point is not accuracy. The point is to learn whether one machine is enough or whether you need many.

Sources disagree on how much to do. The SRE workbook drives its exercises to real machine counts, yet says sound reasoning and assumptions matter more than the final values. It also rounds up aggressively so a design does not hit a limit early.

Hello Interview's delivery framework says upfront estimates are often unnecessary, and suggests doing maths only when it will directly change the design. Our middle path is up to five minutes, spent only on numbers that pick between designs.

Here are the candidate's sums as a few lines of Python. On the board you would do them in your head, but code shows each step. The peak factors and the record size are assumptions, said out loud before use.

SECONDS_PER_DAY = 86_400

def per_second(per_day, peak_factor):
    average = per_day / SECONDS_PER_DAY
    return round(average), round(average * peak_factor)

parcels = 2_000_000      # parcels a day (made up)
scans = parcels * 10     # about 10 scans per parcel
reads = parcels * 5      # about 5 status checks per parcel
bytes_per_scan = 200     # assumed size of one scan record

print("scans/s (avg, peak):", per_second(scans, peak_factor=3))
print("reads/s (avg, peak):", per_second(reads, peak_factor=10))
print("raw scan data per year, GB:", scans * bytes_per_scan * 365 / 1e9)

Save it as estimate.py and run python3 estimate.py. You should see exactly this:

scans/s (avg, peak): (231, 694)
reads/s (avg, peak): (116, 1157)
raw scan data per year, GB: 1460.0

What just happened? Scans average 231 a second and reach about 694 at peak. Status reads reach about 1,157 a second at peak. Raw scan records grow by 1,460 GB, about 1.5 terabytes a year, before indexes and copies.

The units matter. GB here means 10 to the power 9 bytes, because the code divides by 1e9. A disk tool that reports binary units shows the same 1,460 GB as about 1,360 GiB.

The peak_factor turns a daily average into the busy-hour number, which is what you design for. Reads get the bigger factor because a festive sale brings crowds of customers refreshing the page.

None of these numbers is huge. About 700 scans a second is within reach of one database server if writes are batched, and the engineer section below measures it. So the hard parts are festive read spikes and never losing a scan, not raw size.

Write three or four API calls and the two or three main tables, nothing more. This takes five minutes and gives every later box something concrete to send and store.

An API, short for application programming interface, is the set of requests other programs can make to your system. The candidate writes three calls on the board.

• record_scan: a hub scanner sends one scan with a scan id, tracking number, hub id, event type and scan time.
• get_status: returns the latest status and expected delivery date for one tracking number.
• get_history: returns every scan for one tracking number, newest first.

For data, there are two tables. A scan_events table keeps every scan, found by tracking number and time. A parcel_status table keeps one row per parcel with only the latest status, so the common read is fast.

That second table is a choice worth saying out loud. It copies facts already stored in scan_events, so every scan costs an extra write. In return, the most common request becomes one simple lookup.

Draw one diagram that follows each main request from the user to the data and back. Keep each box simple, and label it with the job it does.

Start with the simplest design that meets the requirements. The candidate's first sketch is deliberately naive: scanners write straight to one database, and customers read from it. That is the right starting point, not the final answer.

Then parts are added one at a time, each with a reason. In the diagram below, see how scans and customer reads take separate paths.

Three new parts need a word each. A load balancer spreads incoming requests across several copies of a service. A queue holds messages in a waiting line until a worker, a background program, picks them up.

A cache is a fast in-memory store for data that is read again and again. Here it holds the latest status of parcels people are checking right now.

Each addition maps back to a requirement. The queue lets scanners finish quickly and lets scans wait out a slow database, which the one-minute freshness rule allows. The cache absorbs festive read spikes before they reach the database.

The candidate names Kafka for the queue because their team runs it at work. Kafka is an open-source event log that keeps messages after they are read, until a retention limit set per topic. Naming a tool is fine only if you can answer follow-up questions about it.

Go where the interviewer points, and if they do not point, pick the part most likely to break at your numbers. Spend about 13 minutes there, one level deeper than the diagram.

The deep dive is where interviewers see how much you really know. Once the big picture is done, the candidate uses a small decision. Start at the top box and follow the answers on the arrows.

The interviewer does not name an area, so the candidate asks what breaks first. Writes are modest, but a lost or wrong scan would break customer trust. The candidate picks the correctness of the scan path.

What a good deep dive covers

• Duplicate scans. A scanner on weak Wi-Fi may resend the same scan, so the worker skips scan ids it has already stored. This is idempotency: doing something twice has the same effect as doing it once.
• Order of events. Scans can arrive out of order, so the worker keeps the status with the latest scan time. An old scan that arrives late cannot overwrite a newer status.
• Partitioning. If one database gets too busy, split the data by tracking number. Each parcel's scans then live together on one machine.
• Cache freshness. When a new scan lands, the worker refreshes the cache entry too, so customers do not see a stale status for long.

Notice that each point names a problem first, then the fix. That order shows you design from failure cases, not from a list of favourite tools.

Name what each choice costs you, then say what happens when each main part fails. A trade-off you raise yourself scores better than one the interviewer has to dig out.

The candidate states three trade-offs.

• The queue keeps scanners fast, but customers may see a scan up to a minute late.
• The parcel_status table makes reads cheap, but every scan now costs two writes.
• Splitting data by tracking number spreads the load, but a report across all parcels must then query every partition.

Then the candidate walks through failures, one part at a time. The table keeps each answer honest by naming its limit, not just its fix.

The first row's limit is the one most candidates miss. The engineer sections below put numbers on it and show the fix for the repeated scans.

The SRE workbook makes a related point about timing. It says deferring reliability issues during design is like accepting fewer features at higher cost. So raise failures while you design, not only when someone asks.

Closing in two minutes

In the last two minutes, sum up the design in four or five sentences. Cover the requirements, the main path, the hardest part and what you would build next. Then stop, and let the interviewer ask.

The most common mistakes are designing before asking, going deep too early, thinking in silence, and naming tools without reasons. A plan fixes most of them.

• Building before asking. You solve a problem the interviewer never set.
• Diving into one table at minute 5. That was the first mock, and it left no time for the big picture.
• Thinking in silence. The interviewer can only judge what you say out loud.
• Listing tools. Saying you would use Kafka, Redis and Cassandra proves nothing without a reason for each one.
• Ignoring hints. When the interviewer asks about one area twice, that is where they want you.

Expectations also change with level. In Hello Interview's guide to levels, Evan King says mid-level candidates should lead the early phases, such as gathering requirements. He expects senior candidates to go deep in around two places.

He also expects seniors to spot limits in their own design and discuss alternatives, and staff candidates to lead almost the entire interview. The Tech Interview Handbook says system design questions usually go to candidates with a few years of experience.

Measure it with pgbench, the load-testing tool that ships with PostgreSQL. The estimate said about 694 scans a second at peak, so test whether the database can save scans faster than that. Use a test database, never production.

Start simple: create a table and a two-line pgbench script that inserts one scan per transaction. The \set line picks a random number, and :client_id is pgbench's built-in id for each connection, so scan ids almost never repeat. ON CONFLICT DO NOTHING skips any that do.

-- scan_insert.sql
\set n random(1, 2000000000)
INSERT INTO bench_scans VALUES ('s' || :n || '-' || :client_id || '-' || random(), 'TRK' || :n, 'at hub', now()::text) ON CONFLICT (scan_id) DO NOTHING;

psql -c "CREATE TABLE bench_scans (scan_id text PRIMARY KEY, tracking text, status text, scanned_at text)"
pgbench -n -c 4 -j 2 -T 15 -f scan_insert.sql

The -n flag skips the vacuum step, which a script without pgbench's own tables requires. Then -c 4 opens four connections, -j 2 uses two threads, and -T 15 runs for 15 seconds. Look for the line that starts with tps, meaning transactions per second.

Each transaction here inserts one row, so tps is rows per second. On our shared 2-vCPU test machine, PostgreSQL 16.15 with default settings gave anywhere from 497 to 5,989 across 16 runs.

The slow end is below the 694 peak and the fast end is eight times above it. The rate changed a lot between runs on this shared machine, so one run there is not a capacity number.

One comparison held in every paired run. We alternated one-row commits with 50-row commits, back to back, six times. The batches wrote 15 to 17 times as many rows a second each time.

What just happened? The limit was mostly commits, not rows. PostgreSQL's documentation says a commit normally waits for its log records to be flushed to permanent storage. For short transactions, that wait is a major part of the total time.

The real worker writes two rows per scan: the scan and the status upsert. Putting both in one transaction keeps commits per second equal to scans per second.

We tested that too, in six more back-to-back rounds. Both writes in one commit saved 1,017 to 3,244 scans a second. Batches of 50 scans, both writes each, saved at least 13,500 a second, more than 19 times the peak.

Your numbers will differ with disks and settings, which is why you run the test. Single-row commits here sometimes fell below the peak, so do not count on them. Batches cleared it by a wide margin in every paired run. The status worker can batch, because it reads scans from a queue.

Scans pile up in the queue, and customers see old status until the workers clear the pile. How long that takes depends on headroom: how much faster the workers can save scans than scans arrive.

Here is the maths for a 5-minute outage during peak, with 700 scans arriving each second throughout. The capacities are made up; try your own.

peak_in = 700            # scans arriving per second at peak
outage_s = 5 * 60        # the status worker is down for 5 minutes (made up)
backlog = peak_in * outage_s

for capacity in (1_400, 1_000, 800):   # scans the workers can save per second
    drain_s = backlog / (capacity - peak_in)
    print(f"capacity {capacity:,}/s: backlog {backlog:,} scans, "
          f"clears in {drain_s / 60:.1f} min")

Run python3 backlog.py and you should see:

capacity 1,400/s: backlog 210,000 scans, clears in 5.0 min
capacity 1,000/s: backlog 210,000 scans, clears in 11.7 min
capacity 800/s: backlog 210,000 scans, clears in 35.0 min

What just happened? The backlog is 700 times 300 seconds, or 210,000 scans. It shrinks only by the gap between capacity and arrivals. At 800 a second the gap is 100, so it takes 35 minutes, seven times longer than the outage.

We checked the formula with a second-by-second simulation of the same queue, first in, first out. It agreed, and it showed when customers are back inside the one-minute promise.

At 1,400 a second, scans are saved within a minute again about 4 minutes after the restart. At 800 a second, that takes about 28 minutes. Freshness is broken from one minute into the outage until then.

So the failure walk-through gains a number. Saying that scans wait in the queue is true but incomplete. Saying that the promise breaks for half an hour without headroom shows you did the maths.

Give every scan a unique id and make the database refuse a second copy. Then let the status change only when the arriving scan is newer than the one already stored.

Repeats are normal, not rare. Kafka's design documentation for version 4.3 says Kafka guarantees at-least-once delivery by default. If a consumer crashes after processing messages but before saving its position, the next one receives some of them again.

Late scans come from the other end. A handheld scanner on weak Wi-Fi may send an 11:00 scan after a 14:00 one. Even a queue that keeps order cannot fix scans that were sent out of order.

Pause and predict. One parcel's scans arrive as picked up at 09:00, out for delivery at 14:00, the same out-for-delivery scan again, then a late at-hub scan from 11:00. What does a naive worker show the customer?

import sqlite3

# Arrival order at the worker. s3 arrives twice (redelivered after a crash).
# s2 was scanned at 11:00 but arrives last (its scanner was offline).
arrivals = [
    ("s1", "TRK1", "picked up",        "2026-10-19T09:00"),
    ("s3", "TRK1", "out for delivery", "2026-10-19T14:00"),
    ("s3", "TRK1", "out for delivery", "2026-10-19T14:00"),
    ("s2", "TRK1", "at hub",           "2026-10-19T11:00"),
]

def run(safe):
    db = sqlite3.connect(":memory:")
    key = "PRIMARY KEY" if safe else ""
    db.execute(f"CREATE TABLE scan_events (scan_id TEXT {key}, tracking TEXT, "
               "status TEXT, scanned_at TEXT)")
    db.execute("CREATE TABLE parcel_status (tracking TEXT PRIMARY KEY, "
               "status TEXT, scanned_at TEXT)")
    for scan in arrivals:
        if safe:
            db.execute("INSERT INTO scan_events VALUES (?, ?, ?, ?) "
                       "ON CONFLICT (scan_id) DO NOTHING", scan)
            db.execute("INSERT INTO parcel_status VALUES (?, ?, ?) "
                       "ON CONFLICT (tracking) DO UPDATE SET "
                       "status = excluded.status, scanned_at = excluded.scanned_at "
                       "WHERE excluded.scanned_at > parcel_status.scanned_at",
                       scan[1:])
        else:
            db.execute("INSERT INTO scan_events VALUES (?, ?, ?, ?)", scan)
            db.execute("INSERT OR REPLACE INTO parcel_status VALUES (?, ?, ?)",
                       scan[1:])
    rows = db.execute("SELECT COUNT(*) FROM scan_events").fetchone()[0]
    status = db.execute("SELECT status FROM parcel_status").fetchone()[0]
    print(f"{'safe ' if safe else 'naive'}: {rows} scan rows, status = {status}")

run(safe=False)
run(safe=True)

Run python3 scan_worker.py. It needs only Python 3 and its built-in SQLite, and you should see:

naive: 4 scan rows, status = at hub
safe : 3 scan rows, status = out for delivery

What just happened? The naive worker stored the repeat, so the history shows one scan twice. It also let the last arrival win, so the parcel moved backwards from out for delivery to at hub.

The safe worker uses two clauses. ON CONFLICT (scan_id) DO NOTHING skips a scan id that is already stored. The status upsert, an insert that becomes an update when the row exists, updates only WHERE the arriving scan time is newer than the stored one.

In that clause, excluded means the row that was about to be inserted. SQLite added this upsert syntax in version 3.24.0 and follows PostgreSQL's form, so the two safe statements work on both.

We ran them on PostgreSQL 16.15 to check. The repeated scan printed INSERT 0 0 for both tables, and the late scan's status update printed INSERT 0 0, meaning zero rows written.

Two limits are worth saying out loud. Newest-wins trusts the scanner's clock, so a device with a wrong clock can still win. The script stores times as text in one fixed format; in production, use a real timestamp column.

Practise by running the full plan on a timer, out loud, on many different questions, until the order feels automatic. Spread these six steps over a few weeks.

1. 1

   Learn the building blocks first

   Know what load balancers, caches, queues, databases and replicas (extra copies of a database) do, and one reason to use each.

2. 2

   Run the plan on a classic question

   Take a well-known problem like a URL shortener. Run all seven steps on a 45-minute timer, even when you feel unsure.

3. 3

   Talk out loud, even alone

   Record yourself. Listen for long silences and for decisions you made without giving a reason.

4. 4

   Do mock rounds with a person

   Ask a colleague to play the interviewer and to interrupt you. Interruptions are part of the real thing.

5. 5

   Review each mock against the table

   Check every phase. Did you finish it on time, and did you say its output out loud?

6. 6

   Repeat until it feels boring

   Do several mocks on different prompts. When you stop thinking about the order, your attention is free for the problem.

In the scenario, the candidate's real round brought a different prompt: a notification service. The plan still held, because it never depended on the question.