Design a news feed

Open a social app and your home feed shows recent posts from the people you follow, in under a second, however many people that is. Behind it is one of the classic trade-offs in system design: do the work when someone posts (copy the post into every follower's feed) or when someone reads (gather posts from everyone they follow)? The answer is "both", and the reason is celebrities. It follows the interview framework phase by phase.

1. The prompt

"Design the home timeline for a social network like Twitter/X or Instagram. Users post, follow other users, and see a feed of posts from the accounts they follow."

Posting and following are simple. The interview is about the read path: making a feed of posts from hundreds of accounts appear in a few hundred milliseconds for 60,000 feed loads a second, when some of those accounts have 100 million followers.

2. Frame the problem

3. What it must do

1. A user can create a post (text and media).
2. A user can follow and unfollow other users.
3. A user can view their home feed of posts from followed accounts, ranked, with infinite scroll.

Not now:

• The ranking model itself: we design the pipeline around it.
• Comments, likes UI and search: separate services.
• Ads: inserted by a separate service into the ranked list.

4. How well it must do it

5. Numbers that change the design

6. The nouns

• User.
• Post.
• Follow: a follower and the account they follow.
• Timeline: per user, a capped list of post ids, newest first.

posts      post_id (time-ordered, Snowflake-style), author_id, text, media_keys, created_at, status (live | deleted)
follows    (follower_id, followee_id), plus a reverse index followee_id → followers   (sharded by user)
timelines  user_id → [post_id, …]   (latest 800, in Redis sorted sets or lists)
users      user_id, follower_count, is_celebrity (follower_count over the threshold)

7. The contract

REST, with the user from the session token.

POST   /v1/posts                     {text, media_keys}  → 201 {post_id}
POST   /v1/follows                   {followee_id}       → 204
DELETE /v1/follows/{followee_id}                          → 204
GET    /v1/feed?cursor=<post_id>&limit=20               → {posts: [...], next_cursor}
GET    /v1/feed/new?since=<post_id>                       → count of newer posts ("12 new posts")

Post ids are time-sortable (Module 20), so "newest first" is "largest id first", and the cursor is just the last id seen.

8. First working version

A post service with a posts table, a follow service with a follows table, and a feed service that assembles feeds on demand.

8.1 Posting

The post service stores the post once with a time-sortable id and confirms. Media was uploaded straight to blob storage beforehand.

8.2 Following

Insert a row in the follows table, and in the reverse index (who follows this account).

8.3 Reading the feed (pull)

Version one pulls: look up the accounts the user follows, fetch each one's recent posts, merge by id, and take the top 20.

9. Make it hold up

9.1 Fan-out on write, on read, or both? fast feeds · scale

9.2 Storing timelines fast feeds · scale

• A timeline is a capped list of post ids (the latest 800) per user, in Redis or Valkey, sharded by user id. Ids, not full posts: a post appears in thousands of timelines but is stored once.
• Skip inactive users: don't fan out to followers who haven't opened the app in 30 days. If one returns, rebuild their timeline on demand by pulling once.
• The timeline cache is rebuildable from the follow graph and posts, so losing a shard means slower feeds for a while, not lost data.
• Fan-out workers read followers in pages from the reverse index and write in batches; they're fed by a "new post" event stream, so posting never waits for fan-out.

9.3 Hydrating posts quickly fast feeds

A feed page needs 20 full posts: text, author name and avatar, like counts. Fetch the 20 post objects from a post cache in one batch (MGET), the authors from a user cache, and counters from a counter store; fill misses from the databases. Like counts can be slightly stale (Module 16). The posts table itself is sharded by post id (or author id) in a wide-column or relational store.

9.4 Pagination and freshness fresh enough

Cursor pagination by post id (Module 07) keeps infinite scroll stable while new posts arrive. Posts that arrive after the user opened the app are counted with "newer than the first id I have" and shown behind a "new posts" button, rather than shifting the page under the reader's thumb. The author's own new post is inserted into their own timeline synchronously, so they see it at once.

9.5 Ranking fast feeds

Most feeds are ranked, not purely chronological. Keep the same skeleton:

• The timeline gives a candidate set: a few hundred recent posts from followed accounts, plus recommended ones.
• A ranking service scores them with a model (engagement predictions, freshness), within a strict time budget.
• The top results are returned.

If ranking is slow or down, fall back to chronological order (graceful degradation, Module 24).

9.6 Deletes and privacy changes deletes are fast

A deleted post must vanish quickly from millions of timelines. Rather than removing it from every list, mark the post deleted and evict it from the post cache: hydration skips it, so it disappears everywhere at once, and timelines are cleaned lazily. The same filter handles blocked users and accounts that went private.

9.7 The whole design after the deep dives

A normal user posts, a celebrity posts, and a follower opens their feed: the hybrid in motion.

10. Interviewer follow-ups

11. When things break

12. Wrap-up and the clock

Trade-offs we made:

• Hybrid fan-out (bounded writes, a few extra reads).
• Ids in timelines with hydration (store once, extra lookups per read).
• Eventual freshness for followers; read-your-writes for authors.
• Lazy deletion through a filter.
• Ranking with a chronological fallback.

What we'd watch:

• Feed p99.
• Fan-out lag.
• Timeline cache hit rate and memory.
• Ranking latency and fallback rate.
• Time from post to followers' feeds.

At 10×:

• More shards and workers.
• A lower celebrity threshold.
• A stricter inactivity rule.

Common mistakes:

• Pull-only feeds at this scale.
• Pushing celebrity posts.
• Storing full posts in every timeline.
• Fanning out to inactive users.
• Offset pagination.
• Deleting from millions of lists synchronously.

13. Try it, check yourself, read more

Compare the work each strategy does. "Celebrities" are accounts above the threshold; each user follows a few of them.

Hybrid assumes each user follows about 5 celebrities, whose recent posts are read from a hot cache at feed time.