Track 2 — HLD Worked Examples

High-Level Design: Examples

15 famous interview problems, walked end to end. Twitter through distributed job scheduler — clarify, size, sketch, deepen, cross-examine. The reasoning that ties theory to interview performance.

This is the largest chapter in the guide because it's where everything converges. The earlier chapters give you the building blocks; this chapter shows the thinking that puts them together. Each example walks through a famous problem the way a senior engineer would — clarifying first, sizing second, sketching third, then deepening into the parts that matter while a critic pushes back at every decision.

Read these slowly. The goal isn't to memorise answers but to internalise the reasoning. Notice how each major design decision has alternatives, explicit tradeoffs, and a defensible rationale. Notice how the cross-examination questions probe weaknesses you may have missed. Over 15 problems, the patterns become obvious and your pattern-matching speed improves dramatically.

How to use this chapter: try each problem on a blank page before reading the walkthrough. Spend 15-20 minutes sketching your own design. Then compare. The point isn't being "right" — it's seeing what considerations you missed, what tradeoffs you didn't explicitly weigh, what failure modes you skipped. Over the 15 examples you build up a pattern library: the questions you should always ask, the math you should always do, the failure modes you should always anticipate.

The methodology

The 5-step framework

Every worked example below applies this framework. Internalise it and the examples become pattern-matching exercises.

Clarify the problem

⏱ 3–5 minutes · Don't skip this — interviewers score it explicitly

Most candidates jump to architecture before they know what they're building. The first 5 minutes are about constraining the open-ended question into something tractable.

Always cover:

Functional scope — what feature subset matters? (Twitter: just the feed, not DMs.)
Read/write ratio — heavy-read like Twitter (1000:1), or heavy-write like a metrics pipeline?
Scale — DAU, peak QPS, total data volume. Force a number, even a guess.
SLOs — what latency is acceptable? What availability target?
Out of scope — name 2-3 things you're explicitly not building.

Pitfall: "Should I include X?" is bad. "I'm going to focus on X because Y, and exclude Z. Sound good?" is good — you're driving.

Estimate (back-of-envelope)

⏱ 3–5 minutes · Quantification is a senior reflex

Compute the numbers that constrain every later decision. Even rough estimates justify "we need sharding" or "a single Postgres is fine".

The four numbers that matter:

QPS — DAU × actions/day ÷ 86400 × peak-factor (typically 3×).
Storage — items/day × bytes/item × retention years. Multiply by replication factor (usually 3).
Bandwidth — bytes/request × QPS. If > 1 Gbps, CDN matters.
Cache footprint — hot-set size. Drives Redis/Memcached cluster sizing.

Pitfall: Numbers without units. "100K" is useless — 100K what, per what? Always say "100K writes/sec" or "100GB/day".

API & data model

⏱ 5–8 minutes · The contract between client and server

Define the surface area before drawing boxes. Forces concrete thinking and surfaces hidden requirements.

Cover:

Endpoints — REST or gRPC; verbs, paths, payloads, idempotency keys where relevant.
Core entities — what's the row look like? Primary key choice (this often locks in partitioning).
Access patterns — list the 3-5 queries this data has to serve. Schema follows access.

Pitfall: Designing the schema as a relational textbook would. Choose for your actual access patterns — denormalise where it helps.

High-level architecture

⏱ 8–10 minutes · Draw the boxes and arrows

Sketch the end-to-end flow. Components only — don't dive into any single one yet. Save deepening for step 5.

Always show:

Client → entry point — load balancer, API gateway, edge cache.
Service tier — what's stateless, what's stateful, where does compute live?
Data tier — primary store choice + cache + any async pipelines (queues, CDC).
Async paths — what happens off the request path (fan-out, indexing, analytics).

Pitfall: Premature optimisation. "Now I'll add a message queue" without a reason that came from steps 1-3. Every box needs a justification anchored in the requirements.

Deepen — pick 2-3 components

⏱ 15–20 minutes · Where the interview is actually decided

The interviewer will steer here. Be ready to deepen on storage choice, hot-key handling, failure modes, consistency tradeoffs. Pick the ones with the most depth-of-reasoning to show.

Senior signals in this phase:

Naming the explicit tradeoff for every decision (latency vs availability, cost vs consistency).
Walking through a failure mode — "what happens if Redis goes down?"
Calling out a scaling phase — "this design works to 10K QPS; at 100K we'd add X."
Anticipating cross-questions before being asked — "the celebrity problem here is…"

Pitfall: Memorising "the answer" to a famous problem. Interviewers smell rehearsed solutions and probe for the tradeoffs you didn't actually consider. Show your work, not your bookmark folder.