Interview prep guide

System Design Interview Prep

A system design interview is 45 to 60 minutes of designing a large-scale system out loud: a URL shortener, a chat app, a news feed. There is no single correct answer. You are scored on how you get from a vague prompt to a defensible architecture. This guide gives you a repeatable framework, a four-week plan, and the questions to practise it on.

Take a timed mock interview Browse the question bank

What system design interviewers score

Most companies use a rubric close to this one. Knowing it tells you where to spend your minutes.

  • 1

    Problem scoping

    Do you turn an open prompt into concrete functional and non-functional requirements before drawing anything?

  • 2

    Estimation

    Can you size traffic, storage and bandwidth well enough to justify your choices?

  • 3

    Architecture

    Is the high-level design coherent, with clear data flow from client to storage?

  • 4

    Depth

    When pushed on one component, can you go several layers down: schema, partition key, cache policy, failure behaviour?

  • 5

    Trade-offs

    Do you name what each choice costs, not only what it buys?

  • 6

    Communication

    Do you think out loud, check in with the interviewer, and adapt when a constraint changes?

A 7-step framework for any system design question

Use the same sequence for every question. The timings assume a 45-minute interview.

  1. 1. Clarify requirements (about 5 minutes)

    List what the system must do, then how well it must do it: latency, availability, consistency, durability. Agree on what is out of scope. Every later decision should trace back to one of these requirements. See system design fundamentals.

  2. 2. Estimate scale (about 5 minutes)

    Turn daily active users into requests per second, peak load, storage per year and read-to-write ratio. You need orders of magnitude, not precision: the point is to decide whether one database is enough or whether you need caching and sharding. See Latency & Performance and Availability in Numbers.

  3. 3. Define the API and data model

    Write the handful of endpoints the clients call and the entities you store. This is where access patterns become visible, and access patterns decide your database and partition key. See API Design & Communication and Data Storage Fundamentals.

  4. 4. Sketch the high-level design (about 10 minutes)

    Draw the request path end to end: client, DNS, load balancer, stateless services, cache, database, and any asynchronous pipeline. Keep it simple enough to work, then say out loud where it will break first. See How Requests Flow Through Systems.

  5. 5. Deep-dive into the bottleneck (about 15 minutes)

    Pick the component that fails first under your estimated load and fix it: a cache in front of a hot read path, a queue in front of a slow write path, replicas or shards for a saturated database. Explain the new failure modes each fix introduces. See Caching Systems, Asynchronous Processing and Database Bottlenecks.

  6. 6. Discuss trade-offs

    Consistency against availability, latency against cost, simplicity against future scale. Interviewers reward candidates who state the downside of their own design before being asked. See Consistency & CAP Theorem, Consistency Models and System Trade-offs.

  7. 7. Cover failures and operations (about 5 minutes)

    What happens when a zone goes down, a cache is cold, or a dependency slows down? Mention timeouts, retries with backoff, circuit breakers, and the metrics and alerts that would tell you something is wrong. See Fault Tolerance & Reliability and Observability & Monitoring.

A 4-week system design study plan

One hour a day is enough. Each week pairs concepts with questions that exercise them, and ends with a timed attempt.

Week 1

Fundamentals and your first designs

Learn how requests move through a system and what the core building blocks do: Introduction & Fundamentals, How Requests Flow Through Systems, API Design & Communication, Data Storage Fundamentals. Then design the beginner questions:

Week 2

Handling scale

Study Scaling Systems, Load Balancing Systems, Caching Systems, Asynchronous Processing and Content Delivery. Practise on:

Week 3

Distributed data and consistency

Study Database Scaling Techniques, Consistency Models, Consistency & CAP Theorem and Service Communication Patterns. Practise on:

Week 4

Advanced questions under time pressure

Work through advanced questions with a 45-minute timer, then review what you skipped. Finish with at least two timed mock interviews.

Common system design interview mistakes

  • ✕

    Drawing before scoping

    Jumping to Kafka and Cassandra before agreeing on requirements makes every later choice unjustifiable.

  • ✕

    Skipping estimates

    Without numbers you cannot explain why you need a cache, how many shards, or whether a single region is enough.

  • ✕

    Naming components without reasons

    "Add a load balancer" is not an answer; "add a load balancer so stateless app servers can scale horizontally and fail independently" is.

  • ✕

    Ignoring the write path

    Many designs handle reads well and fall over on writes, fan-out or hot keys.

  • ✕

    No failure story

    Every component fails. Say what the user sees when it does.

  • ✕

    Talking in monologue

    Check in with the interviewer at each step; they are often steering you towards the deep dive they want.

How to practise with PRISM

Reading solutions builds recognition, not recall. In PRISM you draw the architecture yourself, run simulated traffic through it, and see which component saturates first. The same loop an interviewer takes you through, on your own schedule.

Practise a question Take a mock interview Follow the roadmap