System Design Interview Template

The interviewer says four words: "Design a URL shortener."

Then they stop talking. Forty-five minutes are yours, the whiteboard is blank, and the silence is doing real damage to your ability to think.

This lesson gives you something to say in the first thirty seconds, and a structure for every minute after it.

What is actually being assessed

Candidates assume they are being marked on whether they produce the right architecture. They are not, because there is no right architecture. Interviewers are judging four things:

1. Do you handle ambiguity? The prompt is deliberately vague. Do you ask, or do you guess?
2. Do your decisions follow from requirements? A cache because you calculated a read-heavy load is engineering. A cache because caches are good is recital.
3. Do you know what you gave up? Every choice costs something. Naming the cost is the strongest signal available.
4. Can you be understood? You will work with these people. Muttering at a whiteboard fails even with a correct design.

The five phases

For a 45-minute interview, budget roughly like this.

Phase 1 — Clarify (about 8 minutes)

Your goal is a written list both of you agree on before anything is designed.

Functional requirements — what it does. Push for the small number that matter:

"Let me confirm scope. A user submits a long URL and gets a short one back; visiting the short one redirects. Should users be able to choose a custom alias? Do links expire? Do we need analytics on clicks?"

Non-functional requirements — how it must behave. These drive the architecture far more than the feature list:

"How many links created per day? What read-to-write ratio should I assume? Is a redirect that occasionally fails acceptable, or must it be near-perfect? Global or single-region users?"

Out of scope — say it explicitly. It protects your remaining time:

"I will assume no user accounts, no billing, and no spam detection unless you would like those included."

Phase 2 — Estimate (about 5 minutes)

Rough numbers decide whether your design needs one machine or a hundred. Nobody expects precision; they expect you to reason with orders of magnitude.

Work in this order: users, then requests per second, then storage, then bandwidth.

Take 100 million new links a day, read 100 times more often than written:

• Writes: 100M ÷ 86,400 seconds ≈ 1,200 per second
• Reads: 1,200 × 100 = 120,000 per second
• Storage: at ~500 bytes per record, 100M × 500B = 50 GB per day, about 18 TB a year
• Peak: assume 2–3x average, so plan for roughly 300,000 reads per second

Now say what those numbers mean, because that is the actual point:

"Reads outnumber writes a hundred to one, so this is a caching problem more than a database problem. 18TB a year rules out a single machine long-term, so I will need to shard. And 300k reads per second means the redirect path has to avoid touching disk."

Phase 3 — API and data model (about 7 minutes)

Defining the interface forces both of you to agree on exactly what the system does before any boxes appear.

Keep it to two or three endpoints:

POST /api/v1/urls        { longUrl, customAlias?, expiresAt? } -> { shortUrl }
GET  /{shortCode}        -> 302 redirect to the long URL

Then the data. State the access pattern first — it justifies the storage choice:

url_mappings
  short_code   VARCHAR(7)   PRIMARY KEY
  long_url     TEXT         NOT NULL
  created_at   TIMESTAMP
  expires_at   TIMESTAMP    NULL

"Every read is a lookup by primary key with no joins, so a key-value store fits naturally. I will keep it relational for now because the data is small and simple, and revisit if we need to shard aggressively."

Phase 4 — High-level design (about 15 minutes)

Only now do you draw. Start with the simplest thing that satisfies the requirements, and say so.

Then walk one request end to end, out loud. This is where most of your marks are earned:

"A redirect arrives at the load balancer and reaches any app server — they are stateless, so any of them can serve it. The server checks the cache; short codes are heavily skewed, so a small cache should absorb most reads. On a miss we read the database and populate the cache. We return a 302."

Explain each choice as you place it, in one sentence: what it does, and why these requirements need it.

Phase 5 — Scale and failure (about 10 minutes)

This phase separates good candidates from great ones. Drive it yourself rather than waiting to be asked.

Find the bottleneck. "At 300k reads per second the single database is the limit, so I will add read replicas and shard by short code."

Remove single points of failure. Point at each box and delete it aloud: "if the cache dies we fall back to the database, which survives but at higher latency. If the load balancer dies everything stops, so we run at least two with failover."

Name the trade-offs you made. "Caching means a recently edited link could serve a stale target for up to the TTL. For redirects that is acceptable; if it were not, I would invalidate on write."

Mention what you would monitor. "P99 redirect latency, cache hit rate, and error rate by status code."

The phrases that earn marks

Specific sentences that signal seniority:

• "Let me start simple and scale it once we see where it breaks."
• "That is a trade-off. I am choosing X, which costs us Y."
• "What breaks first here is…"
• "I do not know that number precisely — may I assume roughly N and adjust?"
• "That is out of scope for now; shall I come back to it if we have time?"

And the ones to avoid: "we would just use Kafka", "it will scale", and any component named without a reason.

Check your understanding

Common mistakes

Designing for a billion users when asked for a thousand. Over-engineering is judged as harshly as under-engineering, because it shows requirements did not drive the design.

Going silent while thinking. The interviewer cannot mark what they cannot hear. Narrate: "I am weighing SQL against a key-value store here…"

Refusing to commit. Listing three options and picking none reads as indecision. Choose one, justify it, and note when you would revisit.

Ignoring the interviewer's hints. "What happens if that server fails?" is not curiosity. It is a gift telling you exactly where to go next.

Running out of time. Watch the clock. A complete simple design beats an unfinished sophisticated one every time.

Practice

Key takeaways

• The prompt is deliberately vague. Clarifying is part of the test, not a delay before it.
• Spend the first fifteen minutes on requirements and numbers. They justify everything that follows.
• Estimate before designing — the numbers decide whether you need one machine or a hundred, and saying what they imply is the point.
• Start with the simplest design that meets the requirements, then scale it deliberately.
• Name every trade-off out loud. Knowing what you gave up is the clearest signal of experience.
• Drive failure analysis yourself: find the bottleneck, delete each box in turn, and say what you would monitor.

That completes the fundamentals. From here the course moves into high-level design, where each component in these diagrams gets examined properly — starting with how a request finds your servers at all.

Further reading

• Google SRE, Site Reliability Engineering (O'Reilly, 2016), chapter 6 — the four golden signals, useful vocabulary for the scale-and-failure phase.
• Martin Kleppmann, Designing Data-Intensive Applications (O'Reilly, 2017) — the reference behind most storage decisions you will be asked to justify.
• Sam Newman, Building Microservices, second edition (O'Reilly, 2021) — service boundaries and the questions that decide them.
• Roy Fielding, "Architectural Styles and the Design of Network-based Software Architectures" (doctoral dissertation, 2000), chapter 5 — the constraints behind REST, worth knowing before defending an API shape.
• Michael Nygard, Release It!, second edition (Pragmatic Bookshelf, 2018) — failure modes and stability patterns, the source material for phase five.