The five-phase framework (45-minute pacing)
- Requirements — 5 minutes. Split functional ("shorten a URL, redirect, custom aliases?") from non-functional (scale, latency targets, availability vs. consistency, durability). Ask for numbers: users, reads vs. writes, data size. Then say your scope aloud: "I'll design for 100M DAU, read-heavy 100:1, sub-100ms redirects, and skip analytics unless we have time." Scoping out loud is the single highest-signal move in the round.
- Estimation — 5 minutes. Back-of-envelope QPS, storage, bandwidth. Round to powers of ten, state assumptions, sanity-check ("500M new URLs/month ≈ 200 writes/sec — modest; reads at 100:1 ≈ 20k/sec — that's the design driver"). The point is not precision; it is showing that numbers drive your architecture choices.
- High-level design — 10 minutes. Boxes and arrows for the happy path: clients, load balancer, stateless app tier, data stores, cache, queue. Walk one request end-to-end aloud. Keep it boring — novelty here is risk without reward.
- Deep dives — 20 minutes. The interviewer picks a component ("how exactly does the ID generation avoid collisions?", "what happens when a cache node dies?"). This is where levels separate. Go concrete: data model, partition key choice, failure modes, what pages the on-call at 3am.
- Wrap — 5 minutes. Bottlenecks you'd attack next, what you'd monitor, what you deliberately skipped. Ending with known limitations reads as seniority, not weakness.
The trade-off vocabulary that signals seniority
Interviewers listen for whether you reach for these axes unprompted:
| Axis | The sentence that scores |
|---|---|
| Consistency vs. availability | "For the follower count I'd accept staleness; for the payment ledger I wouldn't — different stores for different guarantees." |
| Latency vs. cost | "Caching the top 1% of keys serves ~90% of reads; caching everything triples memory for a marginal hit-rate gain." |
| Push vs. pull | "Fan-out-on-write for normal users, fan-out-on-read for celebrity accounts — hybrid, keyed on follower count." |
| SQL vs. NoSQL | "The access pattern is key-value by short code with no joins — that's what makes a wide-column store defensible here, not fashion." |
| Sync vs. async | "The user needs the write acknowledged; the notification fan-out can ride a queue and be eventually delivered." |
The meta-rule: never name a technology without naming the property that earns it a place. "Kafka" is a word; "a partitioned log so consumers can replay after failure" is a reason.
The ten most common prompts, with the crux of each
- URL shortener. Crux: ID generation (counter + base62 vs. hash + collision handling) and read-path caching. Classic warm-up — expect follow-ups on analytics and expiry.
- Chat system (WhatsApp/Slack). Crux: connection management (WebSockets, presence), message ordering per conversation, delivery guarantees and receipts, offline sync.
- News feed (Twitter/Instagram). Crux: fan-out strategy and the celebrity problem; ranking as a separate service; pagination via cursors, not offsets.
- Rate limiter. Crux: algorithm choice (token bucket vs. sliding window), distributed counting (Redis + Lua), fail-open vs. fail-closed, and where it sits (gateway vs. per-service).
- File storage (Dropbox/Drive). Crux: chunking and deduplication, sync protocol and conflict resolution, metadata vs. blob separation.
- Video platform (YouTube). Crux: upload pipeline (transcoding as async jobs), CDN strategy, adaptive bitrate; storage economics.
- Ride matching (Uber). Crux: geospatial indexing (geohash/quadtree), location update write volume, matching as a stateful service, surge as a pricing feed.
- Notification system. Crux: multi-channel abstraction (push/email/SMS), per-user preferences and rate caps, idempotency and retry with dedupe, priority queues.
- Distributed cache. Crux: consistent hashing, eviction policy, cache-aside vs. write-through, thundering herd protection (request coalescing, jittered TTLs).
- Metrics/monitoring system. Crux: time-series write volume, downsampling and retention tiers, tag cardinality explosion, alert evaluation as streaming computation.
Practice at least three end-to-end, out loud, on a whiteboard or doc, at 45-minute pace. Narrating a design and writing one are different skills — the interview grades the narration. A mock with an AI interview assistant gets you transcript-level feedback on exactly where your explanation lost the thread; ChadFlow can also watch your diagram window during a live round and help when a follow-up lands.
The five ways candidates fail this round
- Skipping requirements. Designing the wrong system beautifully is the most common failure. Thirty seconds of scoping prevents it.
- Estimation theater. Doing arithmetic and then never using the numbers. If your QPS estimate doesn't change your design, it was performance art.
- Buzzword architecture. Dropping Kafka/Cassandra/Kubernetes without the property-based justification above.
- Monologuing. The round is a collaboration test. Check in: "want me to go deeper on the storage layer or move to the API?"
- No failure story. Every component you draw should have an answer to "what happens when this dies?" Prepare the answer before you draw the box.
Narrate designs like you've done it before.
ChadFlow transcribes your mock design rounds, coaches your explanations between sessions, and helps live with a window-selective view of your diagram — invisible to screen share.
Download ChadFlow