How to prepare for a system design interview

Six abilities, and every question exercises several of them. They are also how every exercise on SysGeeks is tagged, so your progress shows which ones you are weak in.

Trace what actually happens

Following a request or event across every boundary it crosses.

Explain the mechanism

Describing how a mechanism works, not just what it is called.

Defend a decision

Choosing between alternatives from the constraints, and naming the cost.

Adapt to new constraints

Finding the new bottleneck when requirements or scale shift.

Reason about failure

Predicting what happens when a component, message, or network misbehaves.

Connect it to code

Turning a guarantee into code that actually enforces it.

1. 1

   Pin down the requirements (about 5 minutes)

   Ask what users do (the functional requirements) and how well it must work: scale, latency, durability, consistency (the non-functional ones). Then state your assumptions out loud, so the interviewer can correct them before you build on them.

2. 2

   Estimate the load (about 5 minutes)

   Requests per second at peak, storage per year, the ratio of reads to writes. Round freely. The point is not the number but what it tells you: which part of the system is under pressure, and which is not worth optimising.

3. 3

   Sketch the high-level design (about 10 minutes)

   Clients, the API, the data stores, and any work that happens asynchronously. Then trace one request from end to end across every boundary it crosses, so both of you agree on what the boxes do.

4. 4

   Go deep where the requirements make it hard (about 15 minutes)

   Every question has one or two hard parts: a hot key, an effect that must happen exactly once, a write that fans out to millions of readers. Put two designs side by side, choose one, and say what it costs.

5. 5

   Break it (5 to 10 minutes)

   A worker dies halfway through a job. A message arrives twice. A request times out after it succeeded. Traffic grows ten times. Say what your design does in each case, and change it where the answer is wrong.

6. 6

   Close with what it guarantees (the last few minutes)

   What the design promises, what it assumes, and where it stops working. Interviewers remember a candidate who knows the limits of their own design.

• A tradeoff named together with its cost, not just its benefit.
• Numbers that change a decision: why one database is enough, or why it is not.
• Mechanisms instead of product names: “a durable queue with acknowledgements”, not “use Kafka”.
• Precise guarantees: at-least-once delivery with an idempotent consumer, not “exactly once”.
• Failure behaviour you volunteer before being asked.
• Changing the design calmly when the interviewer changes a constraint.

• Drawing boxes before agreeing on the requirements, then designing for the wrong problem.
• Designing for a billion users when the question implied ten thousand.
• Presenting one design as the answer, with no alternative and no reason.
• Treating a cache, a queue or a retry as free: each adds a failure mode of its own.
• Saying nothing about what happens when a component dies or a network call times out.
• Going silent while thinking. The interview grades your reasoning, so it has to be audible.

• Caching

  Keeping a copy of data closer to where it is used, trading freshness and complexity for speed and reduced load on the source.

• Message queues

  A durable buffer between producers and consumers that hands each message to one consumer at a time and redelivers it unless acknowledged.

• Idempotency

  Designing an operation so that performing it twice has the same effect as performing it once, which is what makes retries safe.

• Delivery guarantees

  At-most-once, at-least-once, and why 'exactly-once' is achieved by making duplicates harmless rather than by preventing them.

• Partitioning

  Splitting data or work by key so each part is handled independently: scaling out, and giving each key a single owner.

• Replication

  Keeping copies of data on several machines for durability, read capacity and locality, and living with copies that briefly disagree.

• Consistent hashing

  Mapping keys to nodes so that adding or removing a node moves only a small share of keys, instead of reshuffling almost all of them.

• Rate limiting

  Capping how fast a client may use a resource, to protect capacity, enforce fairness, and stay within the limits of the systems you depend on.

• Timeouts and unknown outcomes

  A timeout bounds how long you wait. It tells you nothing about what happened, so the operation's outcome becomes unknown.

• Transactional outbox

  Recording outgoing messages in the same database transaction as the state change, then delivering them separately, to avoid the dual-write problem.

• Fan-out on write and fan-out on read

  When one write must reach many readers, do the work when it is written (precompute every reader's view) or when it is read (assemble it on demand). Most real feeds do both.

• Backpressure and capacity

  When work arrives faster than it can be done, something has to give: the queue grows, the producer slows, or work is shed. Choose which on purpose.

How long is a system design interview?

Usually 45 to 60 minutes for a single problem. Expect around 5 minutes on requirements, 5 on estimates, 10 on the high-level design, 15 on the hardest part, and the rest on failures, scale and questions.

Do junior engineers get system design interviews?

Sometimes, in a lighter form. They become standard from mid-level roles upwards, and for senior roles the system design round often decides the level of the offer.

What is the difference between high-level and low-level design?

High-level design (HLD) is about services, data stores and how requests and data flow between them. Low-level design (LLD) is about the inside of one component: its classes, interfaces and data schema. Most system design interviews are high-level, with a deep dive into one component.

Should I memorise designs for common questions?

No. Interviewers change a constraint precisely to see whether you understand why a design works. Practise the reasoning instead: decide, explain the mechanism, break it, and adapt it when the requirements move.

How should I practise for a system design interview?

Work through whole systems from their requirements, out loud or in writing, and check your reasoning against a worked answer. Practise failure scenarios deliberately, since that is where most candidates are weakest. Finish with timed mock interviews.

Is SysGeeks free?

Yes. SysGeeks is free, needs no account, and keeps your progress in your browser.