How to design a News Feed (Twitter Timeline)

What a strong answer covers

• Uses the read/write ratio: precomputing moves work to the much rarer side.
• Fan-out runs asynchronously, so posting stays fast.
• Timelines store IDs, not copies, so content lives in one place.
• Anticipates that very large audiences make write-time fan-out expensive.Supporting

In this order

1. 1The write API stores the post durably and assigns its ID
2. 2A fan-out job is enqueued and the author's request returns
3. 3A fan-out worker asks the social graph for the author's recently active followers
4. 4For each follower, it pushes the post ID onto their timeline list and trims the list to 800
5. 5The follower's app asks the timeline service for the first page
6. 6The service reads a page of IDs and hydrates them into posts, dropping deleted ones

What a strong answer covers

• One post from a huge account becomes millions of writes that delay everyone.
• Few accounts are that large, and each reader follows few of them, so read-time merging is cheap.
• Those accounts' recent posts are hot and cacheable.
• Mentions choosing the threshold, or the extra merge latency on reads.Supporting

Tradeoffs

What the fix has to do

• Store references (IDs) in timelines and hydrate on read, so deletes and edits apply everywhere at once.
• Cap each list (LTRIM to 800) as part of the insert.
• Page through followers and pipeline the inserts in batches rather than one awaited round trip each.
• Fan out only to active followers, and skip huge accounts.Supporting

Reference implementation

const newestFirst = (a: string, b: string) => (BigInt(b) > BigInt(a) ? 1 : BigInt(b) < BigInt(a) ? -1 : 0);

export async function homeTimeline(userId: string, before: string | null, limit = 50): Promise<Post[]> {
  const [own, large] = await Promise.all([
    timelineIds(userId, before, limit),
    largeAccountsFollowed(userId),
  ]);
  const fromLarge = await Promise.all(large.map((a) => recentPostIds(a, before, limit)));

  const page = [...new Set([...own, ...fromLarge.flat()])].sort(newestFirst).slice(0, limit);
  const posts = await hydrate(page);
  return page.flatMap((id) => {
    const post = posts.get(id);
    return post ? [post] : [];
  });
}
// The client asks for the next page with before = the last ID it received.

What a strong answer covers

• Fetches the precomputed page and the large accounts' recent posts in parallel.
• Merges by ID (time), newest first, de-duplicating, and takes only the page size.
• Applies the same 'before' cursor to every source so pages do not overlap or skip.
• Hydrates IDs and drops posts that no longer exist (deleted).
• Compares 64-bit IDs numerically (BigInt), not as strings of different lengths.Supporting

What a strong answer covers

• Ranking signals change after the post is written, so scores must be computed at read time (or refreshed).
• Precomputed timelines become cheap candidate generation for the ranker.
• Ranking is bounded by the candidate set size, not the whole graph.

Reference answer

What a strong answer covers

• Uses the ratio and fan-out numbers to show which side should pay.
• Explains why caching does not rescue pull: each reader's merge is different, so the merged result is not shared.
• Concedes the real costs: two read paths, memory, and rebuild work after failures.
• Names conditions under which pull (or a different split) would win.