Design a News Feed: System Design Interview Guide

The news feed question (design Facebook/Instagram/Twitter feed) is one of the most frequently asked system design interviews at FAANG and high-growth startups. It tests whether you can reason about read-heavy fan-out architectures, ranking under latency constraints, and consistency tradeoffs at scale. This guide walks through the full interview flow: requirements gathering, fan-out strategy selection, ranking, real-time delivery, and pagination.

Clarifying Requirements

Before touching architecture, nail down scope with the interviewer. A typical set of functional requirements:

• Users can publish posts (text, image, video) to followers.
• Users can view a reverse-chronological or ranked feed.
• Feed supports pagination (infinite scroll).
• System supports likes, comments, and shares surfaced in the feed.

Non-functional requirements that shape every downstream decision:

• Read-heavy workload: reads outnumber writes by roughly 100:1 to 1000:1.
• Low latency: feed load under 200ms p99.
• Eventual consistency acceptable (a new post can take seconds to propagate).
• High availability preferred over strict consistency (AP over CP in CAP terms).

Fan-out on Write vs Fan-out on Read

This is the central architectural decision in the news feed problem, and interviewers expect you to discuss the tradeoff explicitly rather than pick one blindly.

Fan-out on write (push model): when a user posts, the system immediately writes that post’s ID into every follower’s precomputed feed (typically stored in Redis or a similar cache). When a follower requests their feed, it’s already been assembled; the read is a cheap cache lookup.

Fan-out on read (pull model): posts are stored once. When a user requests their feed, the system fetches recent posts from everyone they follow at request time and merges/ranks them on the fly.

Most production systems (Twitter, Facebook, Instagram) use a hybrid model: fan-out on write for regular users, fan-out on read for celebrities/high-follower accounts, with results merged at serve time. State this hybrid explicitly in the interview — it demonstrates you understand the celebrity problem without needing to be prompted.

Ranking Algorithm

Modern feeds are not strictly reverse-chronological. Interviewers increasingly expect a ranking discussion, even at a high level.

A practical ranking approach for the interview:

1. Candidate generation: gather a pool of recent posts from followed accounts (typically last 24-72 hours), plus posts surfaced by engagement signals from a secondary retrieval path.
2. Feature scoring: score each candidate using features like recency decay, author affinity (how often the viewer interacts with this author), post engagement velocity (likes/comments per minute), and content type weighting (video vs text).
3. Light ML model or weighted formula: score = w1*recency + w2*affinity + w3*engagement_velocity + w4*content_type. In a 45-minute interview, a linear weighted model is sufficient; mentioning that production systems use a learned model (e.g., a gradient-boosted tree or a lightweight neural ranker) shows depth without over-engineering the whiteboard.
4. Re-ranking for diversity: avoid showing five consecutive posts from the same author; interleave content types.

Real-Time Updates

Feeds need to reflect new posts and interactions without a full page reload. Two common approaches:

• Long polling / WebSockets: client maintains an open connection; server pushes new feed items or notification badges (“3 new posts”) as they arrive.
• Client polling with ETags: simpler, less real-time, but far easier to scale and debug — the client polls every N seconds and the server returns 304 if nothing changed.

For most interviews, proposing a lightweight notification channel (WebSocket or Server-Sent Events) that tells the client “new content available, tap to refresh” is preferable to silently re-ordering a feed the user is actively scrolling — this preserves scroll position and avoids user-perceived flicker.

Feed Pagination

Offset-based pagination (LIMIT 20 OFFSET 40) breaks down for a feed because the underlying data set is constantly changing — new posts shift every subsequent page, causing duplicates or skipped items.

Use cursor-based pagination instead: return an opaque cursor (typically an encoded timestamp + post ID) with each page, and require the client to pass it back for the next page. This guarantees stable pagination even as new content is inserted at the head of the feed.

Putting It Together in the Interview

A strong answer sequence: requirements → back-of-envelope estimation → high-level architecture diagram → deep dive on fan-out strategy → deep dive on ranking → real-time delivery → pagination → bottlenecks and mitigations. Interviewers reward candidates who proactively raise the celebrity fan-out problem and cache invalidation strategy without being prompted — it signals you’ve actually thought about production-scale feed systems, not just textbook diagrams.

If you’re building a structured 0-to-1 prep routine rather than cramming individual questions the night before, The 0-to-1 SWE Interview Playbook (Amazon: https://www.amazon.com/dp/B0H256Z1MF?tag=sirjohnnymai-20) walks through this exact question sequencing across the full system design category, not just news feed.

Common Mistakes

• Jumping straight to a database schema before establishing read/write ratios.
• Ignoring the celebrity problem entirely — a near-guaranteed follow-up question.
• Proposing strict consistency for feed delivery, which is unnecessary and costly at this scale.
• Forgetting to discuss cache invalidation when a user deletes a post or unfollows someone.

Treat this question as a lens on distributed systems fundamentals — fan-out, caching, consistency, and pagination — rather than a feed-specific trivia exercise. The same fan-out and ranking patterns recur in notification systems, activity streams, and recommendation feeds across nearly every interview loop in 2026.