Questions That Actually Come Up

Name the three core endpoints before drawing a single box — POST /api/tweets, GET /api/timeline, POST /api/users/{id}/follow — and say out loud why each one earns its place: one is the write, one is the hard read problem, one is the edge that makes a timeline personal. Then rattle off what you're deferring — search, notifications, rate limiting, caching — in one breath, and name 2–3 things explicitly out of scope, like DMs or ads. Doing this unprompted is what separates "I'm scoping deliberately" from "I don't know where to start."

Talk through the arithmetic out loud instead of stating a memorized number. For example: "Say 500M daily active users, each opening their timeline ~10 times a day — that's 5B reads/day, roughly 58K QPS average and 3–5x that at peak. Tweet writes are far lower — maybe 500M tweets/day, ~6K QPS." The specific numbers matter less than demonstrating the read:write ratio explicitly, since that ratio is the fact that justifies caching and fan-out before an interviewer has to ask why.

Pull (compute the timeline at read time by merging each followed user's recent tweets) is simple but too slow once someone follows thousands of accounts. Push (fan out a new tweet into every follower's precomputed timeline at write time) makes reads instant but breaks down for accounts with huge follower counts — a celebrity's tweet would mean millions of writes. The hybrid answer — push for most users, pull-and-merge at read time for celebrity accounts — is the one worth landing on, because it shows you've identified where each approach fails rather than picking one dogmatically.

This is the fan-out hot-key problem in disguise. Pushing one tweet to 100M timelines synchronously would take the write path down; the fix is to exclude very-high-follower accounts from push fan-out entirely and merge their tweets in at read time instead, plus lean hard on caching so that read isn't hitting the database repeatedly. Naming this tradeoff unprompted — "push works until an account has too many followers, and here's what breaks first" — is a strong signal on its own.

Start from the access pattern, not a database brand. A single relational table is fine at low scale and gives you strong consistency for free. Once you need to shard for write throughput, a wide-column store like Cassandra or DynamoDB lets you model the schema around the query — one table keyed by tweet ID, a denormalized second table keyed by author ID for the profile timeline — trading storage duplication for avoiding cross-shard queries. Say the tradeoff explicitly rather than asserting "NoSQL scales better," which is the answer that sounds memorized.

Auto-increment breaks the moment you shard, since two shards can't both hand out ID 501 next. The answer is a Snowflake-style generator: pack a timestamp, a machine ID, and a per-machine sequence number into one 64-bit integer, so any node mints unique, roughly time-sortable IDs with zero coordination with any other node. Bring this up as the direct consequence of sharding, not as a fact recited on its own.

New tweet writes should still be durably accepted if the log itself is replicated (Kafka's own replication handles this), but every downstream consumer — fan-out, search indexing — stalls until it recovers, since they only learn about a write by reading the log. The honest answer is that the write path stays up but the product degrades: new tweets exist but won't show up in anyone's timeline or search results until the log is healthy again. Naming that distinction — write availability vs. downstream staleness — shows you understand what the log actually decouples.

If tweets were pushed into precomputed timelines, a delete has to be fanned out too — an async job that removes the tweet ID from every follower's timeline cache/store, mirroring the write path structurally. Until that job completes there's a real (if short) window where the tweet is deleted but still visible in a cached timeline — worth naming as a deliberate eventual-consistency tradeoff rather than a bug.

This is the classic read-your-writes problem: if the fan-out job hasn't finished, refreshing your own timeline immediately after posting might not show your own tweet yet. The common fix is to special-case it — merge the user's own most recent tweets into their timeline at read time regardless of fan-out status, so they always see their own posts immediately even if their followers' fan-out is still catching up.

Split it by subsystem: write-path health (tweet ingestion success rate, log lag), read-path latency (timeline p99, cache hit rate), and fan-out lag (time between a tweet being written and it landing in followers' timelines). A dropping cache hit rate or growing fan-out lag are both leading indicators of trouble before users notice — pointing at those specifically, instead of a generic "I'd monitor uptime," is what shows operational thinking.

A hard fixed-window counter is the wrong first instinct — it either lets a burst double the effective rate at a window boundary, or feels unfair to someone rapid-firing a few legitimate requests. A token bucket per user, refilling continuously, tolerates short bursts up to the bucket size while still enforcing a long-run average — naming the fixed-window boundary problem with actual numbers ("100 requests at 0:59, 100 more at 1:00") is the detail that proves you understand why.

Don't answer with a random feature — answer with whatever the design's current weakest assumption is. A strong version names something already flagged in this guide: hot-key replication for viral tweets, cross-region replication for global latency, or a real anomaly-detection layer on top of rate limiting rather than a static threshold. It shows you know your own design's edges rather than treating it as finished.