System Design Problems

Clarify functional vs non-functional requirements and explicitly cut scope. Cause→effect chain:

• You ask "is this read-heavy or write-heavy? Do we need the timeline, DMs, search, trending — or just post + follow + timeline?" → the interviewer narrows it to post a tweet, follow users, view home timeline.
• That narrowing → you commit to non-functional goals: highly available, eventual consistency is OK (a tweet showing up 1–2s late is fine), timeline latency under ~200ms.
• Defining "eventual consistency is acceptable" up front → unlocks aggressive caching and async fan-out later, which a strongly-consistent design would forbid.

Trade-off / cost: every feature you keep (search, media, trending) multiplies the design surface. Spending 3–5 minutes cutting scope costs you a little time now but prevents the far worse outcome of running out of time with a half-built everything. The risk is cutting too much and looking like you don't understand the product — so name what you're deferring, don't pretend it doesn't exist.

Do the back-of-envelope math out loud. Cause→effect chain:

• 200M DAU, each posts ~2 tweets/day → 400M writes/day ÷ 86,400s ≈ ~4,600 writes/sec (call it ~5K, peak maybe 2–3× → ~12K/s).
• Each user refreshes the timeline ~20 times/day → 4B reads/day ÷ 86,400 ≈ ~46,000 reads/sec (peak ~100K/s).
• Reads outnumber writes ~10:1 → this is a read-heavy system → you should precompute timelines (fan-out on write) and cache hard, rather than building the timeline fresh on every read.
• Storage: 400M tweets/day × ~300 bytes ≈ 120 GB/day → ~44 TB/year of text alone → you'll need sharding and a plan for cold-data archival.

Trade-off / cost: these estimates justify your architecture, but precision is a trap. If you spend 10 minutes computing exact byte counts you've burned your design time. Round aggressively, state assumptions, and move on — the number's job is to point you at "read-heavy, must precompute," not to be audited.

The API is the contract that constrains everything downstream. Cause→effect chain:

• Writing getTimeline(userId, pageToken, count) → forces you to admit timelines are paginated with a cursor, not an offset → because offset pagination (LIMIT 20 OFFSET 10000) makes the DB scan and discard all 10,000 skipped rows, so cost grows with how deep you scroll, while a cursor (last-seen tweet ID/timestamp) is an index seek whose cost stays roughly constant regardless of scroll depth.
• Including an apiKey / auth token param → signals you'll rate-limit and authenticate at the gateway, not inside business logic.
• Defining the response shape (list of tweet IDs vs hydrated tweet objects) → decides whether the timeline service returns IDs and clients hydrate separately, which keeps the timeline payload tiny and cacheable.

Trade-off / cost: a cursor-based API is harder to implement and can't easily "jump to page 500," but for an infinite-scroll feed nobody jumps to page 500, so you pay almost nothing for a big scalability win. The cost of skipping the API step is that you design services with mismatched assumptions and discover the contract conflict mid-diagram.

Split by access pattern, not by tidiness. Cause→effect chain:

• Tweets are append-only, huge volume, queried by author and by ID → store in a wide-column / NoSQL store (e.g. Cassandra) sharded by tweet ID → because 44 TB/year won't fit one SQL node and you never need cross-tweet JOINs on the hot path.
• The follow graph (who-follows-whom) is relationship-heavy and read constantly during fan-out → a dedicated followers table indexed by followeeId → [followerIds] → because fan-out needs "give me everyone who follows Alice" in one cheap lookup.
• User profiles are low-volume, need strong consistency (email, password) → keep in a relational store.

Trade-off / cost: splitting into three stores means no foreign keys and no transactional JOIN across them — you accept eventual consistency and must handle dangling references (a tweet whose author was deleted) in application code. That's the price of each store scaling independently. A single Postgres is simpler and fully consistent but caps you at one machine's write throughput, which ~12K writes/sec will eventually blow past.

Pick fan-out based on the read:write ratio you computed earlier. Cause→effect chain:

• Reads are ~10× writes → you'd rather do work once on the rare write than repeatedly on the frequent read → favor fan-out on write: on post, push the tweet ID into every follower's precomputed timeline cache (a Redis list per user).
• Result → getTimeline becomes a single cache read of pre-merged IDs → ~200ms target is easily met because there's no merging at read time.
• The write goes async through a message queue (Kafka) → the post API returns immediately while a fan-out worker fills timelines in the background.

Trade-off / cost: fan-out on write explodes for celebrities — a user with 100M followers triggers 100M cache writes per tweet, and most of those followers are inactive, so you've burned huge work for nothing. That's the celebrity / hot-key problem, and naming it here is exactly what sets up your deep-dive. Fan-out on read avoids that explosion but makes every timeline load do an expensive merge, missing your latency target for normal users.

Use a hybrid keyed on follower count. Cause→effect chain:

• For normal users (say under ~10K followers) → fan-out on write as before → cheap because the fan-out is bounded and most timelines stay warm.
• For celebrities (millions of followers) → do NOT fan out; their tweets are pulled at read time → because writing to 100M lists per tweet is wasteful when those followers' timelines are read far less often than the celebrity tweets.
• At read time → merge the user's precomputed timeline (from normal follows) with a fresh pull of the handful of celebrities they follow → a small merge of, say, 50 precomputed + 20 celebrity tweets → still well under 200ms.

Trade-off / cost: the hybrid adds real complexity — you now maintain two code paths, a threshold to tune, and a merge step that must dedupe and re-sort by time. You also need to define what "celebrity" means and handle a user crossing the threshold. This is the right level of detail for a deep-dive: you're trading implementation complexity for the only design that survives both the common case and the worst case.

Proactively attack your own design — naming failure modes before the interviewer does is high signal. Cause→effect chain:

• The timeline cache (Redis) is the hottest component → if a node dies, thousands of timelines vanish at once → mitigate with replication + sharding by userId, and treat the cache as rebuildable: the source of truth is the tweet store and the follow graph → so a lost cache node degrades to a slower read while it rebuilds, not data loss.
• The fan-out worker queue is the second pressure point → a sudden spike (a celebrity event, a viral moment) backs up Kafka → because workers can't drain fan-out fast enough → mitigate by scaling workers horizontally and letting the queue absorb the burst, so the post API stays fast and timelines just lag a few seconds (acceptable under your eventual-consistency goal from step 1).
• A single celebrity's tweet is a hot key at read time → every follower pulls the same record → mitigate by caching that celebrity's recent tweets in a small, heavily-replicated hot cache so the read load spreads across replicas instead of hammering one shard.

Trade-off / cost: every mitigation buys resilience by spending money and complexity — replicas double your cache footprint, more workers cost compute, and a hot-tweet cache is another layer to keep coherent. The reason it's worth it: each one converts a hard failure (data loss, a stalled write path, a melted shard) into graceful degradation (a slower read, a few seconds of lag). That trade — paying steady infrastructure cost to avoid catastrophic, user-visible outages — is the judgment the interviewer is listening for, and it loops straight back to the consistency and latency targets you committed to in step 1.