Interview Horizon All guides

Interview guide

System design interview exercises

This page is a standalone HTML document on the same host as Interview Horizon. Use it to practice the parts of a system design interview that are not a framework: requirements, capacity, data, APIs, and failure.

Requirements before boxes

Start with the user, the write path, and the read path. Ask what happens when the system is wrong: lost money, stale feed, or delayed notification. Write non-functional targets as numbers: p99 latency, durability, and how stale a read may be.

Interviewers listen for the questions you ask before you draw. If you skip them, the diagram is decoration.

Capacity you can estimate

Pick peak QPS, average payload, and retention. Convert to storage per day and to a rough machine count. The arithmetic can be coarse; the discipline cannot. Name the bottleneck you would measure first: CPU, disk, or a hot key.

Data modeling

Choose a source of truth. Decide what is stored, what is computed, and what is cached. Call out the key you would shard on, and what happens if that key is skewed.

Do not default to a global SQL database unless you can say why transactions matter more than write throughput for this product.

APIs and backpressure

Sketch the public API and one internal queue. Idempotent producers, bounded consumers, and an explicit retry policy beat a whiteboard of arrows. If a downstream dependency slows, say whether you shed load, queue, or fail the user request.

Failure and operability

Kill a zone, a disk, and a deploy. For each, name the user-visible symptom and the rollback. Add one metric and one log field you would search at 3 a.m.

Practice prompt

Design a URL shortener that must stay available during a region loss and must not assign the same short code twice. Timebox 25 minutes. Cover:

  1. Write path uniqueness.
  2. Read path latency.
  3. Redirect analytics that may lag.
  4. What you would cut if the interview has five minutes left.