SYSTEM DESIGN · THE METHOD

The LADDER method

Six steps for any design question, sized for a 45-minute interview. It is built to fix the three pieces of feedback candidates hear most: didn't clarify, didn't ask, didn't know the basics. Every design problem on AlgoRung is walked through in this order.

  1. LListen and clarify
  2. AAsk about scale
  3. DDefine the API and data
  4. DDraw the high-level design
  5. EExpand the hard part
  6. RReview trade-offs
L

1. Listen and clarify

About 3 min

Repeat the problem in one sentence. Fix the scope: which features are in, which are out.

Ask the interviewer

  • Is this for one region or global?
  • Do we need X, or just the core flow?
  • Who are the users: consumers or internal teams?

They will ask you

  • Why did you leave that out?
A

2. Ask about scale

About 4 min

Get the numbers: users, requests per second, data size, read/write ratio. Do back-of-the-envelope math out loud, but only where the numbers change the design.

Ask the interviewer

  • How many daily active users?
  • Reads vs writes?
  • How long do we keep data?

They will ask you

  • So how many servers is that?
  • What is the storage per year?
D

3. Define the API and data

About 5 min

Write the 3 to 5 core endpoints and the main records. Pick SQL or NoSQL and say why.

Ask the interviewer

  • Is strong consistency required here, or is a few seconds of lag fine?

They will ask you

  • What is the primary key?
  • How do you paginate?
D

4. Draw the high-level design

About 8 min

The simplest system that works: client, load balancer, service, database, cache. Trace one request end to end.

Ask the interviewer

  • Is this the shape you had in mind, or should I go deeper on one part?

They will ask you

  • What happens when the database goes down?
E

5. Expand the hard part

About 15 min

Pick the one or two hardest requirements and go deep: sharding, fan-out, consistency, hot keys. This is where the score is decided.

Ask the interviewer

  • Which part matters most to you: latency, consistency or cost?

They will ask you

  • How does this behave at 10x?
  • Where is the single point of failure?
R

6. Review trade-offs

About 5 min

Name what you traded away, the failure modes, how you would monitor it, and what you would do next.

Ask the interviewer

  • Anything you would like me to revisit?

They will ask you

  • Why not X instead?

Three rules that go with it

  1. Never draw before you ask. The first five minutes are questions. Every clarifying question in our walkthroughs is written on the page with the answer it got.
  2. Say the trade-off before the interviewer asks. Every component you add gets one sentence: what it costs.
  3. Depth beats width. One hard part explained well scores more than ten boxes. Senior candidates are expected to find the hard part themselves; mid-level candidates can let the interviewer point to it.

The 45-minute checklist

The 25 questions interviewers ask most

Each one links to the concept episode that answers it. Episodes marked "coming" are on the way, one a day.

  1. What happens when you type a URL into the browser? Episode 1: What Happens When You Type a URL? →
  2. How does DNS work, and why do changes take time to spread? Episode 2: DNS: How the Internet Finds Any Website →
  3. What does HTTPS add over HTTP? Episode 3: HTTP vs HTTPS: What the S Really Does →
  4. How does a load balancer pick a server, and what happens when one dies? Episode 5: Load Balancers Explained →
  5. Reverse proxy vs load balancer: what is the difference? Episode 6: Reverse Proxy vs Forward Proxy →
  6. REST vs GraphQL vs gRPC: when would you use each? Episode 8: API Design: REST vs RPC vs GraphQL →
  7. WebSockets vs long polling vs SSE? Episode 9: Real-Time: WebSockets, Long Polling and SSE →
  8. Where would you add a cache, and how do you keep it consistent? Episode 11: Caching: Where It Lives and What Goes Wrong →
  9. What is a CDN and what should go on it? Episode 12: CDN: How Static Files Get Close to Users →
  10. Monolith or microservices for this system, and why? Episode 13: Monolith vs Microservices: When to Split →
  11. SQL or NoSQL here? Justify it. Episode 16: SQL vs NoSQL: How to Choose →
  12. Why is this query slow, and what index fixes it? Episode 17: Indexes: Why a Query Is Fast or Slow →
  13. What does ACID mean in practice? Episode 18: Transactions, ACID and Isolation Levels →
  14. How does replication work, and what happens on leader failure? Episode 20: Replication: Leader-Follower, Multi-Leader, Leaderless →
  15. How would you shard this table? What is the shard key? Episode 21: Sharding and Partitioning →
  16. What is consistent hashing and why does it matter? Episode 22: Consistent Hashing →
  17. Explain the CAP theorem with this system as the example. Episode 25: CAP and PACELC in Plain Words →
  18. Strong vs eventual consistency: which does this feature need? Episode 26: Consistency Models: Strong, Eventual, Read-Your-Writes →
  19. When do you use a message queue? Kafka vs a simple queue? Episode 28: Message Queues and Pub-Sub →
  20. How do you make an operation idempotent? Episode 29: Idempotency and Retries →
  21. How would you rate limit this API? Episode 30: Rate Limiting Algorithms →
  22. How do you generate unique IDs across many servers? Episode 32: Clocks, Ordering and Unique IDs →
  23. How do you keep two services consistent without a distributed transaction? Episode 33: Distributed Transactions: 2PC, Sagas, Outbox →
  24. How do you estimate storage, QPS and bandwidth for this? Episode 36: Back-of-the-Envelope Estimation →
  25. How would you know this system is healthy in production? Episode 37: Observability: Logs, Metrics, Traces →

Practise it

41 design problems, from a URL shortener to a stock exchange, each walked through in exactly this order.

The design problems →