3. Twitter / News Feed Intermediate → Advanced

A. Realistic Interview Prompt

This is the canonical "fanout" problem — the entire design hinges on one question: do you compute a user's feed when they post, or when their followers read? Both answers are individually simple; the difficulty is that neither answer works uniformly for every user, because follower-count distributions on a real social graph are wildly skewed (a handful of accounts with 100M+ followers, the vast majority with a few hundred). A design that treats all users identically has already missed the core insight.

B. Difficulty

Intermediate to start — "write posts to a table, read posts from people you follow" is a five-minute answer — escalating to Advanced the moment the interviewer asks what happens when a celebrity with 100M followers posts, or when the feed needs to be ranked instead of chronological. Structurally similar to Rate Limiter in that a clean naive answer exists, but the real signal is entirely in the deep dives.

C. What This Problem Tests

• Whether you independently arrive at "fanout-on-write vs. fanout-on-read" as the central trade-off, rather than needing it spelled out
• Recognition that a single strategy fails at the tails of a skewed distribution (celebrities), and the judgment to apply a hybrid rather than forcing one strategy everywhere
• Read/write ratio reasoning — feeds are read orders of magnitude more than posts are written, so the design should shift work toward write time wherever the fanout width allows it
• Comfort with a precomputed, denormalized "inbox" data model (one entry per follower per post) instead of reflexively normalizing everything
• Knowing where ranking, search, and media serving are separable concerns layered on top of the feed-delivery core, not part of it

D. Requirements

Functional

1. Users can post short text updates (optionally with media) and follow/unfollow other users
2. Users can view a feed composed of posts from people they follow, ordered by recency (baseline) or relevance (extension, Q)
3. Users can like, reply to, and repost/retweet content

Non-Functional

• Read-heavy at extreme scale — feed reads vastly outnumber posts written; this document uses 200M DAU, each checking their feed ~5×/day and posting ~10% of the time as the standard illustrative input, deriving all downstream QPS from it in G
• Low latency feed loads — a feed should render in <200ms; this is a "check my phone" interaction, not a batch job
• Eventual consistency is acceptable — a new post appearing in a follower's feed a few seconds late is a non-issue; this is the single assumption that makes async fanout tractable
• Highly available for reads — a feed failing to load is a much worse user experience than a post being delayed by a few seconds

Out of scope: direct messages, notifications infrastructure, ad insertion, detailed content moderation — each is its own design problem.

E. Clarifying Questions

F. Assumptions

• Confirmed: post, follow, and reverse-chronological feed read are the core functional loop.
• Assumption: the social graph has real celebrity accounts with 10M+ followers — the standard, most-interesting version of this problem, and what every major source (Hello Interview, ByteByteGo, the donnemartin repo) converges on.
• Assumption: chronological feed is the base design (J-T); ranking is an explicit, clearly-flagged extension (Q), not baked in from the start — mirrors Rate Limiter's structure of "solve the core problem, then layer the harder extension."
• Assumption: eventual consistency for feed delivery (a few seconds of fanout lag is fine) — this is the load-bearing assumption for the entire async design.
• Assumption: media is supported but delegated to a separate blob-store + CDN path (R), not stored in the feed/post database itself.

G. Capacity Estimation

H. Core Entities

I. API Design

POST /v1/posts               { text, media_url? } -> { post_id, created_at }
POST /v1/follows             { followee_id }
DELETE /v1/follows/{id}
GET  /v1/feed?cursor=&limit= -> { posts: [...], next_cursor }
POST /v1/posts/{id}/like

Why a cursor, not an offset, for pagination: the feed is a live, constantly-growing precomputed list (O) — an offset-based page 2 can skip or duplicate entries as new posts fan in between requests; a cursor (typically an encoded timestamp+post_id) is stable against concurrent inserts, the same reasoning behind cursor-based pagination in most high-write-throughput feeds.

J. Basic / Naive High-Level Design (V1) — Fanout-on-Read

The simplest correct design: store posts in one table; to build a feed, query the posts of everyone the user follows, at read time, and merge-sort by recency.

V1 — nothing is precomputed. Every feed load re-queries and re-merges from scratch.

Why this doesn't scale, specifically: if a user follows 500 accounts, loading their feed means 500 separate lookups (or one large fanned-out query) plus an in-memory merge, on every single feed load — and per G, feed loads happen ~50× more often than posts are written. This design does the most expensive part of the work (the fanout/merge) at the highest-frequency point in the whole system (read time) — precisely backwards for a read-heavy workload. It is, however, immediately correct for new-post visibility (no fanout lag at all) and worth naming as V1's one genuine advantage before replacing it.

K. Data Model & Store Choice

Posts and the follow graph: a relational or wide-column store (e.g. Postgres/MySQL for posts, or a graph-friendly store for follows) — this data is the durable source of truth and benefits from real schema/indexing.

The precomputed feed/inbox (FeedEntry): a wide-column store or Redis sorted set, keyed by user_id, with post_ids ordered by a score (timestamp, or a rank score once Q is layered in). Why a sorted set, not a relational table: the access pattern is "give me the top N entries for this user, ordered by score" — exactly what a sorted set's ZREVRANGE does in O(log n), and precisely the same "the store's native data structure already matches the access pattern" reasoning used for Redis in the Rate Limiter and URL Shortener problems.

L. End-to-End Flow — Fanout-on-Write (Post → Delivery)

Why the queue between the write and the fanout: the exact same reasoning as URL Shortener's analytics pipeline — the fanout can be arbitrarily slow (celebrity-scale, per G) and must never sit on the critical path of "did my post succeed." The author gets their 201 the instant the source-of-truth write lands; fanout happens asynchronously afterward.

M. Deep Dive 1 — Fanout Strategy: Write vs. Read vs. Hybrid

Requirement this addresses: the core read/write imbalance from D and G — this is the single most important decision in the whole problem.

Why hybrid, not one uniform strategy: the follower-count distribution is the entire crux (E's clarifying question 2) — the two strategies fail at opposite ends of it. Fanout-on-write is clearly right for a user with 200 followers (cheap, and gives their followers a fast read); it is clearly wrong for a user with 10M followers (one post shouldn't trigger 10M synchronous-ish writes). Treating "average follower count is low" as license to use one strategy everywhere is the single most common mistake on this problem — the average hides exactly the tail that breaks the design.

N. Deep Dive 2 — The Celebrity Problem, In Detail

Requirement this addresses: directly extends M — this is where the hybrid strategy's threshold and mechanics get concrete.

The threshold check happens once, at post time — not a runtime cost paid on every read for every user.

Why a follower-count threshold, and why it's cheap to check: follower_count is deliberately denormalized onto the User entity (H) specifically so this check is a single field read, not a COUNT(*) over the follow graph on every single post. The threshold itself (Hello Interview and ByteByteGo both use illustrative values in the hundreds-of-thousands-to-low-millions range) is a tuning knob, not a hard constant — the point being tested is recognizing that a threshold-based split is needed, not memorizing the exact number.

The follow/unfollow edge case this creates: a normal user's feed is a static, precomputed list plus a live merge of celebrity content — meaning if a user follows a new celebrity, nothing needs to be backfilled into their feed at all (celebrity content is always merged live); but if a user follows a new *normal* user, the follow event itself must NOT retroactively push that user's back-catalog into the new follower's feed — only new posts going forward. Getting this backfill boundary right (new posts only, never historical) is a common subtlety worth naming explicitly.

O. Deep Dive 3 — The Precomputed Feed/Timeline Store

Requirement this addresses: Latency (D) — the <200ms feed-load target is only achievable if the read is a single cheap lookup, not a computation.

Why one row per (follower, post), not a join: a normalized design would join Follow and Post at read time — exactly V1's mistake, just moved one layer down. The precomputed FeedEntry model deliberately duplicates data (the same post_id appears once per follower) in exchange for making the read O(1)-ish (one sorted-set range query). This is a direct, worthwhile application of denormalize-for-reads, the same trade-off implicit in every cache-aside pattern in the URL Shortener problem, just applied to a primary data structure instead of a cache layer.

Bounding the size: feeds don't need infinite history precomputed — capping each user's stored feed at, say, the most recent ~800 entries (per E's clarifying question 5) bounds memory per user regardless of how prolific their followees are; anything older falls back to a (rarer, acceptable-latency) on-demand fanout-on-read query.

P. Deep Dive 4 — Caching Viral / Hot Posts

Requirement this addresses: a distinct hot-spot problem from N — N is about fanout write cost for celebrity authors; this is about read cost when one specific post goes viral and is fetched by an enormous number of readers nearly simultaneously.

Why normal cache sharding doesn't fix this: a single viral post_id hashes to one shard no matter how many shards exist — identical in shape to the Rate Limiter's hot-key problem (Q in that section), just triggered by read fan-in instead of one abusive writer.

• Full replication for hot content — instead of sharding a viral post's data, replicate it across every cache node (or a dedicated small pool of nodes), so read traffic for that one post is spread across all of them rather than hammering one shard.
• Local, short-TTL in-process caching at the edge/API-server layer — a post that's hot right now is still hot 500ms from now; a very short local cache absorbs a large fraction of read fan-in before it ever reaches the shared cache tier.
• Detecting "hot" dynamically — track access frequency per key and promote a post into the replicated tier automatically once it crosses a threshold, rather than guessing in advance which posts will go viral.

Q. Deep Dive 5 — From Chronological to Ranked Feed

Requirement this addresses: the explicit extension flagged in F/E — replacing "most recent first" with "most relevant first."

Ranking is a separable layer, not a rearchitecture: the precomputed FeedEntry sorted set already supports an arbitrary score, not just a timestamp. Swapping recency for a relevance score — a weighted function of recency, the reader's affinity to the author (past interactions), predicted engagement (likes/replies), and content type — changes what gets written as the score at fanout time, not the storage/delivery mechanism from O.

Why fanout still matters even with read-time ranking: ranking needs a bounded candidate set to score — the precomputed feed/inbox from O is exactly what narrows "every post ever" down to "the few hundred candidates worth ranking for this user," so the ranking layer sits on top of the fanout design, not instead of it.

R. Deep Dive 6 — Media Storage & Delivery

Requirement this addresses: the media-support assumption from F — images/video have a completely different size and access profile than post text.

Why media never touches the post DB or feed store: a video attachment can be MB-GB in size — storing it inline would blow out row sizes in a store optimized for small, frequent reads (O). Instead: media uploads go to a blob store (S3-class object storage), the Post row stores only a URL/reference, and reads are served via a CDN fronting the blob store — the same "don't put large binary data in your hot-path database" principle, and the same CDN-for-static-content pattern used for redirects in the URL Shortener problem, just applied to media bytes instead of a redirect response.

S. Deep Dive 7 — Search

Requirement this addresses: the explicit extension flagged in E's clarifying question 4 — a genuinely different access pattern (full-text/keyword) from timeline delivery by follow-graph.

Why the feed store (O) can't serve this: the sorted-set-by-user model is built for "give me this user's feed ordered by score" — it has no notion of matching arbitrary text across all posts globally. Search requires an inverted index (Elasticsearch/OpenSearch-class system), populated asynchronously off the same "new_post" event stream already used for fanout (L) — one write, two independent async consumers (fanout worker, search indexer), each free to fail or lag independently without affecting the other.

T. Full Solution at Scale — Final Architecture

Everything above is the composition of M through S — no new component introduced here.

U. Design Evolution

• V1 — fanout-on-read (J): correct, but puts the expensive merge on the highest-frequency path.
• V2 — fanout-on-write for everyone: fixes the read-cost problem, but a single celebrity post now triggers a write storm (M).
• V3 — hybrid fanout with a follower-count threshold: solves the celebrity write-storm problem (M, N).
• V4 — precomputed, capped, sorted-set feed store: hits the <200ms read target (O).
• V5 — replicated caching for viral posts: handles read fan-in on one hot post that write-side sharding alone can't (P).
• V6 — relevance scoring at fanout time: upgrades chronological to ranked without changing the delivery mechanism (Q).
• V7 — blob store + CDN for media: keeps large binary content out of the hot-path stores (R).
• V8 — async search indexer off the same event stream: adds full-text search without coupling it to the fanout path (S).

What stays stable throughout: the GET /v1/feed contract from I and the append-only "new_post" event from L — every version underneath changes without the client noticing.

V. Consistency Model

Deliberately eventually consistent almost everywhere, matching D's NFR directly: a follower seeing a new post a few seconds after it's published (fanout lag) is a non-issue, and a search result lagging the live feed by longer still is equally fine (S). The one place closer-to-immediate consistency matters is the author's own read-after-write view of their own post — a user who just posted expects to see it on their own profile instantly, which is why the author's own timeline reads from the source-of-truth Post DB directly (or a cache populated synchronously at write time), not through the same async fanout path their followers use.

W. Failure Scenarios

• A fanout worker crashes mid-fanout: the message queue's redelivery/at-least-once semantics ensure the event is reprocessed; fanout writes (ZADD) are naturally idempotent, so reprocessing is safe (L).
• The feed store shard for a hot user goes down: that user's reads degrade to a fallback fanout-on-read query against the Post DB — slower, but available, not a hard outage (O, N).
• A celebrity post's live merge is slow: bound the celebrity-merge window (e.g. only their last N posts) so a slow merge degrades gracefully rather than blocking the whole feed load (N).
• The search indexer falls behind: isolated entirely to the search path — feed delivery is unaffected, since it's a fully independent consumer of the same event stream (S).
• A write storm from an unexpectedly-viral normal-user post (follower count under the celebrity threshold, but the post itself goes viral): handled by P's read-side hot-key mitigations, not by N's write-side threshold, since N only protects against a large existing follower base, not an unpredictable spike in engagement.

X. Bottlenecks & Scaling Boundary

Y. Design Trade-Offs

Z. Common Bad Designs

• Fanout-on-write for every user with no celebrity carve-out. Works in a demo with a few hundred users; falls over the instant one account has millions of followers — the single most common mistake on this problem.
• Fanout-on-read presented as "the" solution with no mention of the read/write ratio from G — technically correct, but ignores the NFR that makes this problem interesting in the first place.
• Normalizing the feed as a join between Follow and Post tables computed at read time — the same V1 mistake, just moved one layer into "the database" instead of "the application," with the same latency consequence.
• Treating ranking as a day-one requirement instead of a layer on top of a working chronological design — leads to spending the whole interview on a scoring model instead of the delivery architecture that actually carries most of the signal.
• Storing media inline in the post/feed tables. Bloats the exact tables that need to stay small and fast for the core read path.

AA. Interviewer Follow-Ups

AB. Interviewer Evaluation Rubric

• Weak candidate: "query posts from people you follow, sort by date" with no mention of precomputation, no awareness of the read/write imbalance.
• Mid-level: proposes fanout-on-write with a precomputed feed store; hasn't yet considered what happens with a very large follower count.
• Senior: proactively raises the celebrity/skewed-distribution problem and proposes a hybrid threshold-based fanout unprompted; separates ranking and search as layered extensions rather than baking them into the core design.
• Staff+: discusses the viral-post hot-key read problem distinctly from the celebrity write-fanout problem; reasons concretely about consistency (author read-after-write vs. follower eventual consistency) rather than asserting "eventually consistent" as a blanket statement.

AC. Interview Simulation

AD. Online Solution Comparison

AE. Interview Cheat Sheet