{"id":11,"date":"2026-01-01T00:00:00","date_gmt":"2026-01-01T00:00:00","guid":{"rendered":"https:\/\/springgreen-curlew-885344.hostingersite.com\/blog\/system-design-interview-guide\/"},"modified":"2026-06-19T05:46:38","modified_gmt":"2026-06-19T05:46:38","slug":"system-design-interview-guide","status":"publish","type":"post","link":"https:\/\/lastroundai.com\/blog\/system-design-interview-guide","title":{"rendered":"How to Walk Through a System-Design Round Without Freezing"},"content":{"rendered":"
The 45-minute system-design round is the round most senior candidates fail. Not because they don’t know the components. Because they don’t know how to spend the minutes. Forty-five minutes feels like a lot until you’ve been silent for six of them, drawing a load balancer.<\/p>\n
This is a phase-by-phase breakdown of what to say, when. The framework is boring on purpose. Most posts on system design try to give you a clever mnemonic. The panels don’t care about your mnemonic. They care about whether you cover the right ground in the right order.<\/p>\n
Minutes 0 to 5: clarify, don’t assume<\/h2>\n
When the interviewer says “design Twitter”, every senior candidate’s instinct is to start drawing. Resist it. The first five minutes are for questions, not boxes.<\/p>\n
Three things to nail down:<\/p>\n
\n
Scope.<\/strong> Tweets, replies, the timeline, search, DMs, notifications. Pick two or three. “I’ll focus on tweet posting plus the home timeline. Skip DMs and search unless we have time.” This single sentence buys you the next 40 minutes.<\/li>\n
Scale.<\/strong> 100 million DAU, 1 million tweets per minute peak, average tweet 200 bytes, 90\/10 read-write skew. Get the panel to either confirm these or correct them.<\/li>\n
Non-functional requirements.<\/strong> Latency target (read p99 under 200ms, post p99 under 500ms), availability (three nines is normal, four nines is a stretch for a side-channel like search), consistency model (eventually consistent timeline, strongly consistent post acknowledgement).<\/li>\n<\/ul>\n
Write each of these on the whiteboard. The panel can see you committed to a scope. You can refer back when you have to trade something off later.<\/p>\n
Minutes 5 to 10: back-of-envelope numbers<\/h2>\n
Estimate, don’t guess. The panel wants three numbers from you in this phase: request rate (QPS), storage growth per year, and bandwidth at peak.<\/p>\n
For the Twitter example: 1M tweets\/min peak \u00f7 60 \u2248 17k writes\/sec. Reads at 90\/10 ratio \u2248 150k reads\/sec. Storage: tweet (200 bytes) + metadata (200 bytes) + index entries (\u2248 400 bytes) \u2248 800 bytes per tweet. 1M tweets\/min \u00d7 60 \u00d7 24 \u00d7 365 \u2248 525B tweets\/year \u00d7 800 bytes \u2248 420 TB\/year. That’s enough for the panel to know you can do napkin math.<\/p>\n
Don’t round to nice numbers. 17k writes\/sec is better than “about 20k”. The panel reads round numbers as fabrication.<\/p>\n
Minutes 10 to 25: the high-level architecture<\/h2>\n
Draw the boxes. Client app, CDN, edge load balancer, API gateway, service tier, cache, primary datastore, async workers. Keep it simple. Six to eight boxes is enough for this phase. The panel will push you to expand specific ones later.<\/p>\n
When you draw, narrate. “I’m using an API gateway here because we want auth, rate limiting, and request routing in one place. Could be Envoy or AWS API Gateway.” Naming specific tools is a positive signal. Hand-waving “a service layer” is a negative one.<\/p>\n
Two patterns the panel expects to see by minute 20:<\/p>\n
\n
Fan-out-on-write timeline.<\/strong> When a user tweets, the post service writes the tweet, then publishes an event to a queue (Kafka, Kinesis), and a fan-out worker materialises that tweet into each follower’s timeline cache. Reads become O(1).<\/li>\n
Celebrity-account exception.<\/strong> Fan-out doesn’t scale when an account has 100M followers. Mention you’d hybrid this: fan-out for normal accounts, pull-on-read for celebrities. This single observation is what separates an L4 from an L5 answer.<\/li>\n<\/ul>\n
Minutes 25 to 35: deep-dive into one or two components<\/h2>\n
The panel will pick something they want you to expand. Usually it’s the timeline cache or the datastore choice. Be ready to defend both.<\/p>\n
For the datastore: don’t say “I’ll use MongoDB” without justifying it. Say “I’d use a wide-column store like Cassandra for the tweet store because writes are append-only, the schema is simple, and we get tunable consistency per-request. For user-profile data which is read-heavy and small, a relational store like Postgres with a read replica fleet is fine. Two different stores for two different access patterns.” That’s what the panel wants to hear.<\/p>\n
For the cache: name the tier (Redis cluster), the eviction policy (LRU with a longer TTL for verified-user timelines), and the warmup strategy (preload on follow event). Mention the failure mode: cache stampede. Mention the mitigation: request coalescing with a single in-flight refresh per key. These are the details that move you from “candidate has read a blog post” to “candidate has actually built this”.<\/p>\n
Minutes 35 to 42: trade-offs and failure modes<\/h2>\n
The last seven minutes are where staff-level candidates earn their level. Walk through three failure modes explicitly:<\/p>\n
\n
What happens if Redis goes down? Read latency spikes from p99 200ms to p99 3s as everything falls back to Postgres. We degrade timeline to a slower path. We do not return 500s.<\/li>\n
What happens if a fan-out worker falls behind? Followers see stale timelines. We monitor consumer lag and page on 30-second consumer lag. We never block tweet posting on fan-out success.<\/li>\n