The System Design Round, One Prompt Carried From Scope to Defended Design

You have a system design interview on the calendar and you want to see how a strong candidate actually spends the 45 to 60 minutes, not another seven-step list. This guide carries one prompt - design a Twitter-scale timeline - all the way through, with the real QPS and storage math, the clock elapsing stage by stage, and a wrong datastore choice caught and reversed. It is for mid-level and senior engineers who can already draw boxes but lose the round on the clock or on a hand-waved estimate.

How to structure a system design interview against a clock

A system design round runs 45 to 60 minutes, and the strongest candidates run it against fixed self-checkpoints rather than an open-ended discussion. The single most useful rule from the public frameworks: by minute 5 clarifying questions are done and you are drawing, by minute 15 the high-level diagram is complete and agreed, by minute 35 you are wrapping deep dives, and at minute 40 you start wrapping up regardless of where you are.

That last clause is the one people ignore. The interview is scored as a whole, not section by section. An omitted section is a zero signal; a compressed one still demonstrates the skill. So at minute 40 you name bottlenecks out loud even if the data model is half-drawn, because compression is always better than omission.

The public sources agree on the spine and differ only on granularity. Requirements to estimation to high-level design to deep dive to trade-offs is the shared skeleton. RESHADED breaks it into eight named steps; ByteByteGo teaches four; interviewing.io publishes a three-step framework for senior engineers. The eight-step version names APIs, schema, and evaluation separately; the three- and four-step versions collapse those into "design" and "deep dive." Pick one and hold to the clock; the granularity matters far less than finishing.

The estimation slot is the one place sources genuinely disagree: most fold it into requirements rather than timing it separately. I keep it as its own three-to-five-minute block, because a hand-waved estimate is one of the cheapest ways to lose the round, and separating it forces you to actually write the numbers down.

The worked prompt: design a Twitter-scale timeline

The prompt for this teardown is "design a Twitter-scale timeline," and I run it end to end so you can follow along on your own case with the real intermediate numbers. I pick this one because it exposes every fork worth rehearsing: a read-heavy workload, a large peak multiplier, a datastore choice with a real trap in it, and a fan-out decision that forces a recovery.

The interviewer states the shape of the problem in the first minute. Users post short text messages. Followers see a reverse-chronological timeline. I need to design the write path (posting) and the read path (loading a timeline). Everything after this is my clock to run.

Minute 0 to 5, I scope. Functional: post a message, follow a user, load a home timeline, load a user's own profile timeline. Non-functional: read-heavy, timeline load under 200 milliseconds, eventual consistency is acceptable for the timeline (a follower seeing a post a second late is fine). Out of scope, said out loud: search, direct messages, media transcoding, ads, notifications. Naming what I am setting aside is the move that closes the clarification window - the interviewer agrees the feature list is bounded, and I start drawing.

A note on a trap I do not step into here. If I had said "we want six nines of availability," that would signal I am behaving like an imposter, because nothing in this design changes between four, five, and six nines. I say "highly available, target four nines" and move on. The number is not the signal; the design decisions it forces are, and here it forces none worth theatre.

Back of envelope estimation, with the real intermediate math

Back-of-envelope estimation is where you compute average and peak QPS and daily storage from stated assumptions, and the peak factor - not the formula - is what separates a strong answer from a bookkeeping one. Everyone can divide 20 million by 86,400. The discriminator is whether you multiply by a stated peak factor, because systems fail at peak, not at average.

Minute 5 to 9, I write the assumptions before any number: 500 million daily active users, 200 million tweets posted per day. The formula is DAU times actions per day, divided by 86,400 seconds. A useful mental shortcut is that a day is roughly 100,000 seconds, so millions per day divided by 100K gives tens per second.

Writes: 200 million tweets over ~86,400 seconds is about 2,300 writes per second average. I state a 10x peak factor for a social platform's morning surge, giving about 23,000 writes per second at peak. Reads dominate: social feeds run about a 100:1 read-to-write ratio, so the timeline read path is the one I provision hardest for. That bandwidth is roughly 500 Gbps for the timeline - a number that immediately tells me the timeline cannot be a synchronous database join on every read.

Storage: the formula is daily writes times retention days times replication factor. Text is about 300 bytes per record. 200 million tweets a day at 300 bytes is ~60 GB of raw text per day; across a year that lands near 50 TB before replication. Media is handled by object storage plus a CDN, never the database, so it stays off this line entirely.

The directional bar matters more than precision. Being off by 2x is fine; being off by 100x means you designed the wrong system. I am not aiming for the exact tweet count. I am aiming to land in the right order of magnitude so my component choices are provisioned for the peak I stated, not the average I could hide behind.

Drafting the API and locking scope by minute 10

By minute 10 the API must be drafted and scope must be locked, because every new feature accepted after this steals time from the design block. This is the checkpoint that prevents the round's most common time sink: re-opening requirements mid-design.

Minute 9 to 11, I write three endpoints and two entities.

POST   /tweets            { userId, text }            -> tweetId
GET    /timeline/home     ?userId&cursor&limit        -> [tweet]
GET    /timeline/user     ?userId&cursor&limit        -> [tweet]

Tweet  { tweetId, authorId, text(<= 280 chars), createdAt }
Follow { followerId, followeeId, createdAt }

Cursor-based pagination, not offset, because offsets get slow and inconsistent as new tweets land at the head of the list. That single word - cursor - is a small correct signal that I have thought about read patterns at scale. Scope is now locked. If the interviewer asks about retweets or replies, I say "same Tweet entity with a parentId, out of scope for the core path unless you want it," which keeps the clock mine.

High-level design: the fan-out fork

The high-level design sketches clients, load balancer, services, datastore, cache, queue, and CDN, then walks the main user flow through them. The fork that defines a timeline system is fan-out: do I build a follower's timeline when a tweet is posted (fan-out on write) or when they open the app (fan-out on read)?

Minute 11 to 15, I draw. Client to load balancer to a stateless Tweet Service and a Timeline Service. A write hits the Tweet Service, which persists the tweet and drops a message onto a queue. A fan-out worker reads the queue and pushes the tweet ID into each follower's precomputed timeline cache. A read hits the Timeline Service, which serves the precomputed list straight from cache. This is fan-out on write, and I say why: reads are 100x writes, so I pay the cost once at write time to make the hot read path a single cache lookup.

I flag the known crack in fan-out on write before the interviewer does: a celebrity with 50 million followers generates 50 million cache writes per tweet, which will melt the fan-out workers. I note it and say "I would special-case high-fanout accounts with a read-time merge, but let me get the base design agreed first." Naming the limit before it is asked is the judgment signal. The interviewer agrees the overall approach. Minute 15, diagram done. I stop drawing even though it is going well - stopping something that is going well to move on is the hardest part of time management, and finishing a section the interviewer already accepts buys me nothing.

The deep dive, and the wrong datastore caught and reversed

The deep dive is where the interviewer picks a component and you reason through its specific trade-off, and it is also where a bad choice must be named and reversed rather than defended. This is the section that most separates a strong hire from a no-hire, because naming a component is not a strong signal - a stated trade-off attached to each named datastore is.

The interviewer asks: what stores the tweets and the follow graph? Minute 15 to 25.

The wrong turn

My first instinct, said out loud, is DynamoDB for everything. It is a defensible default - in interviews you can often justify DynamoDB for almost any persistence layer, because its value is zero operations, not superior technology. Single-digit millisecond latency, or microseconds with DAX. I write "Tweets: DynamoDB, partition key authorId."

Then the interviewer asks the question that catches it: "You want the home timeline to fan out and merge tweets across many authors with tunable consistency per query. How does that work on DynamoDB?" This is where I would be tempted to bluff "set the read to quorum." That is a factual error. DynamoDB is either eventual or strong - there is no QUORUM, no ONE, no ALL. Its global secondary indexes are eventually consistent, full stop.

The recovery

I name the limit, name the alternative, and switch. "You are right, DynamoDB has no per-query quorum tuning, and if I wanted ONE/QUORUM/ALL levels I would use Cassandra, which is AP with tunable consistency and was originally built at Facebook for inbox search - a timeline-shaped problem, later adopted by Netflix, Discord, and Apple." I move the tweet store and the timeline store to Cassandra and keep the follow graph on DynamoDB where a simple strong-or-eventual key lookup is all I need.

The recovery scores higher than the original correct-looking choice would have, because it shows I know the actual constraint boundary of each system rather than a fluent-sounding label. Compression is always better than omission, and a caught reversal is the opposite of an omission - it is the skill on display.

One more limit to keep in your pocket: DynamoDB has a 400KB item size limit. A single tweet is nowhere near it, but if the interviewer pushes toward storing a full precomputed timeline blob per user, that cap is exactly where the "DynamoDB for anything" answer breaks and you move the blob to a cache or Cassandra.

A caught and reversed datastore choice scores higher than a wrong one defended to the last minute.

Where this round gets lost: failure modes and false positives

Most system design rounds are lost on a handful of repeatable mistakes, and each has a false positive that looks fine on the surface. Learn the check for each, because the interviewer is running the same checks in their head.

• Estimation skipped or hand-waved. Candidates who skip estimation design over-engineered systems for small problems or under-engineered ones that collapse under load. Check: did you state DAU and a peak factor before choosing components?
• Designing for average, not peak. The false positive is a clean QPS number that is secretly the average. Average QPS is a bookkeeping number; systems fail at peak. Check: did you multiply by a stated peak factor? The Twitter case jumps from 2,300 to 23,000 on the 10x alone.
• Number-of-nines theatre. Saying "we want six nines" when nothing in the design changes between four and six signals an imposter and invites harsher follow-ups. Check: ask yourself what changes between four and five nines - if nothing, drop the number.
• Naming a component as if it were reasoning. Naming components is not a strong signal. Check: is there a stated trade-off attached to every named datastore?
• Pattern name-dropping. When you name a pattern, the interviewer uses it as an entry point to ask what problems it solves, what new problems it introduces, and how it behaves under failure. Check: can you explain its failure behavior calmly? Restraint - recognizing when a pattern is unnecessary - is one of the strongest signals.
• "A NoSQL database" instead of a named one. The false positive is fluent vocabulary with no concrete system. Check: did you name Cassandra, DynamoDB, or Spanner and its consistency model?
• Finishing a going-well section instead of moving on. Check: at minute 15, is the high-level diagram done, or are you still perfecting a part the interviewer already agreed to?

Practicing the recovery, and keeping your prep current

The tested skill is composition, not recall, so practice recovering from a wrong choice rather than memorizing correct ones. Know maybe 15 problems well and be able to reason from first principles about the other 185; the engineer who memorized 10 fixed architectures freezes the moment the 11th appears. One reference frames it as roughly 50 recombinable patterns; another as seven core patterns you learn to recognize and combine. Either way, breadth protects you against the unfamiliar prompt, not the familiar one.

The vocabulary interviewers expect is set by where the talent concentrates. In Refolk's index of professional profiles, about 13,700 US software and backend engineers list System Design and Distributed Systems skills, clustered at Meta, Databricks, Datadog, Glean, and Cursor. The same profile in India returns about 3,460 people - roughly a quarter of the US pool - with Google, Amazon, and LTIMindtree among top employers. That concentration is why the standard "answers" recur: Cassandra-originated-at-Facebook, DynamoDB-is-zero-ops. Rehearsing against the people who set those expectations beats rehearsing against a generic bank.

When you want to study how engineers who have actually shipped these systems describe their work, you can search for them by exact skill and employer rather than guessing. Refolk writes your resume from your own history and tailors it per posting, and the same index lets you find and read the profiles of people who built the fan-out and event-pipeline systems you are being asked to design.

Here is the full procedure, matching the clock this guide has run. Rehearse it against your own prompt until the checkpoints are muscle memory.

To keep this current, re-run the clock against one unfamiliar prompt a week and force a deliberate wrong turn in the deep dive so you practice the recovery, not just the correct path. The frameworks and the datastore facts here are stable; what drifts is your speed to the minute-15 checkpoint, and that only improves with reps against a running timer.