The Delivery Framework

The first five minutes decide the next forty. The most common reason a strong engineer fails is not a missing algorithm — it is designing the wrong system brilliantly because they never narrowed the prompt.

Separate functional from non-functional. Functional is what the system does (post a tweet, redirect a URL). Non-functional is how well (p99 latency, availability, scale). "Fast and reliable" is neither — it is a non-answer.

Pick exactly three functional must-haves. List everything the prompt implies, then commit to three and explicitly park the rest. Three is enough to be a real system and few enough to design deeply in the time you have. Senior candidates deliver three features thoroughly; juniors sketch eight superficially.

Put a number on every non-functional requirement. "Scalable" → "100M DAU, 20K peak read QPS". "Fast" → "p99 read under 200 ms". The five that apply almost everywhere: latency, availability, durability, consistency, scale. Name all five; quantify at least three.

Bundle your assumptions and invite one correction. "I'll assume consumer, global, two-year retention, read-heavy by 100:1 — push back if any of that is wrong." One sentence beats three minutes of clarifying questions.

Estimation is not arithmetic theatre. Do the numbers that change a decision and say so; skip the rest out loud ("storage is trivial here, I won't size it").

The handful that usually matter:

• Peak QPS from DAU: DAU × actions/user ÷ 86,400, then ×2–3 for peak. This decides whether one database is enough or you shard.
• Storage over the retention window: rows/day × row size × retention. This decides sharding and tiering.
• Bandwidth if you serve media: QPS × payload size. This decides whether a CDN is mandatory.

Anchor to real capacity so you can right-size: a single Postgres handles ~10K–50K TPS and terabytes; Redis does ~100K+ ops/sec; one app server ~1K–10K rps. Quoting these stops you from sharding a system that does 1K QPS.

The senior move is to derive a number and immediately use it: "That's 20K write QPS — past a single primary, so I'll shard by user_id." A number you don't act on was a number you didn't need.

Before architecture, establish what the system stores and how clients talk to it. This gives the high-level design a concrete target instead of an abstract shape.

Core entities — the nouns. List the handful of domain objects (User, Tweet, Follow; or ShortLink, ClickEvent). You don't need a full schema yet — just the entities and their key relationships, so the data model has a spine.

API — the contract. One line per must-have feature, mapped to an endpoint:

• POST /tweets {text} → 201 with id
• GET /feed?cursor=… → page of tweets
• POST /follow {userId}

State the shape, the pagination (cursor, not offset, at scale), the idempotency story for writes that can be retried, and the error semantics. Picking REST vs gRPC vs GraphQL is a one-liner justified by the consumer: REST at the public edge, gRPC between services, async for anything over a second.

Keeping this phase tight means your high-level design has endpoints to wire up, not vibes.

Now draw the system. The goal is a diagram where you can trace each must-have feature across the boxes — not a museum of every component you know.

Start from the canonical request path and adapt: client → edge (CDN/LB) → stateless services → data tier, with an async side-channel (queue + workers) for anything that does not have to block the response.

Drive it from the API. Walk each endpoint through the boxes: "POST /tweets hits the gateway, the tweet service writes to the DB and enqueues a fan-out job." If a feature has no path through your diagram, the diagram is incomplete; if a box serves no feature, delete it.

Justify each component by a requirement. A cache because reads are 100× writes; a queue because fan-out is slow; a CDN because you serve media globally. "I added Kafka because it's good" is a yellow flag — "I added a queue so the write path doesn't block on fan-out" is the senior version.

Keep it legible. A clean seven-box diagram that satisfies the requirements beats a twenty-box sprawl you can't explain.

The high-level design proves you can build the thing. The deep dives prove you can build it at scale — and this is the phase that separates levels. Spend the most time here.

Pick the one or two hardest parts and go deep, ideally the ones tied to your tightest non-functional requirements:

• The bottleneck under load (the hot path at peak QPS).
• The scaling lever (sharding key, cache strategy, fan-out on write vs read).
• The failure mode (what happens when the DB, region, or queue dies).
• The consistency edge (read-your-writes, idempotency, exactly-once myths).

Let the interviewer steer, then go deeper than asked. When they probe "what if this shard gets hot?", don't give one sentence — name the detection, the mitigation, and the trade-off. Quantify: "at 50K writes/sec the single primary tips over, so I shard by user_id; the cost is cross-user queries now scatter-gather, which I push to an analytics replica."

Name trade-offs out loud. Every senior answer is "X buys us A at the cost of B." Interviewers are explicitly told to probe trade-offs and to doubt your answers — meeting that with a calm "here's the tension and here's why I chose this side" is the strongest signal you can send.

Don't let the interview just run out of time mid-sentence. Take the last two minutes to close deliberately — it leaves a senior final impression.

Recap against the requirements. "We've got tweet creation, the home feed, and follows, all under the latency targets. Reads are cache-served, writes fan out async."

Name the biggest trade-off you made. "The main tension was feed freshness vs read latency — I chose fan-out-on-write for fast reads, accepting heavier write amplification for celebrity accounts, which I'd handle with the hybrid approach."

Say what you'd do with more time. "Next I'd harden the multi-region failover and add the abuse / rate-limiting layer." This shows you know what's unfinished — which is itself senior signal — rather than pretending the design is complete.