My dashboardSign in

Backend system design interview

Six weeks from the vocabulary of distributed systems to designing a payment system against the clock.

Start with week 1Open the Backend board

The interview

You get a product to build behind an API, such as a URL shortener, a feed or a ride-hailing service, and 45 minutes to scope it, size it and design the services and storage that keep it up at scale.

Your route

6 weeks, 5 phases

The 45 minutes

A way to spend the time that leaves room for the part that’s hard. Practise against it until it feels natural.

  1. 0–5 minRequirementsAgree what it must do and the qualities that matter most.
  2. 5–10 minEstimatesTraffic, storage and bandwidth, rounded to what changes the design.
  3. 10–17 minAPI and dataThe calls clients make, and the records behind them.
  4. 17–29 minHigh-level designServices, storage and how a request flows through them.
  5. 29–41 minDeep divesThe one or two parts that are hard at this scale.
  6. 41–45 minWrap-upBottlenecks, failures and what you’d do next.

What interviewers listen for

  1. 01ScopingYou ask before you draw, and you write down what you’re leaving out.
  2. 02NumbersYour estimates decide something: a cache, a shard count, a queue.
  3. 03Trade-offsEvery choice comes with the alternative you rejected and why.
  4. 04FailureYou say what happens when a node, a region or a dependency goes down.

Week by week

  1. Week 1

    Foundations

    Speak the language of distributed systems.

    You’ll be able to explain

    • How services call each other, and what a timeout really means
    • Strong versus eventual consistency
    • How systems fail, partially and silently
    • Turning a product idea into requests per second and terabytes

    PractiseEstimate the daily writes, reads and storage of an app you use every day, in five minutes, on paper.

    Check yourselfWhere would eventual consistency surprise a user of that app?

  2. Weeks 2–3

    Building blocks

    Know each standard part well enough to choose it, and to say when not to.

    You’ll be able to explain

    • Routing traffic: DNS, load balancers and CDNs
    • Picking a database for a workload
    • Caching and its invalidation
    • Queues and pub/sub for work that can wait

    PractiseFor each block, write one sentence on when you would use it and one on when you wouldn’t.

    Check yourselfWhich database would you pick for a chat history, a product catalog and a leaderboard, and why?

  3. Week 4

    Patterns at scale

    Handle the problems that only appear with lots of traffic.

    You’ll be able to explain

    • IDs that stay unique across machines
    • Counting hot keys without locking
    • Scheduling and retrying background work
    • Search, logs and metrics you can actually operate

    PractiseTake a design you already know and find its hottest key. Redesign around it.

    Check yourselfHow would you know, at 3 a.m., that this system is failing?

  4. Week 5

    Classic designs

    Run the full interview, end to end, on the questions that come up most.

    You’ll be able to explain

    • A repeatable order: requirements, numbers, API, data, design, deep dive
    • Choosing which part deserves the deep dive

    PractiseDo each design against a 45-minute timer, following the interview clock above. Stop when time is up.

    Check yourselfIn which stage did you run out of time, and what did you skip?

  5. Week 6

    Hard designs and mocks

    Stay calm on the designs with money, location or real-time collaboration in them.

    You’ll be able to explain

    • Exactly-once effects with idempotency
    • Geospatial lookups
    • Real-time delivery and ordering
    • Contention for a limited resource

    PractiseTwo timed mock interviews with a friend. Record them and score yourself against the four signals.

    Check yourselfCould you defend your riskiest choice to someone who disagrees with it?

Common pitfalls

  • Drawing boxes before agreeing what the system must do.
  • Estimates that don’t change any decision.
  • One database, one server, no story for failure.
  • Designing for a billion users when a thousand were asked for.
  • Spending the deep dive on the easy part.