Skip to main content
Let’s design a news feed for an interview question. Be precise about what “news feed” means: in interviews it’s the main, scrollable list of posts or items you see on the first screen of a social app—not the whole app. Examples:
  • On LinkedIn the first screen shows posts from people you follow — that is its news feed.
  • On X (formerly Twitter) the first screen shows tweets from accounts you follow — that is its news feed.
A feed is a sorted list of posts that users can endlessly scroll. Our job is to design a system that efficiently builds and serves that list under realistic constraints.
A centered smartphone mockup shows a dark-themed social media/news feed with posts, icons, and a small image thumbnail. The words "News Feed" are displayed above on a black background.
We’ll follow a six-step framework, beginning with clarifying requirements. At this stage, gather the minimum set of functional and non-functional requirements needed to scope the design. Step 1 — Clarify requirements
  1. What goes into the feed and how is it ordered?
    • If the interviewer limits the feed to posts from accounts a user follows and asks for newest-first ordering, the problem reduces to timestamp-based sorting. If instead a ranking algorithm is required, that becomes a larger ranking problem that needs signals (post age, creator relationship, likes/reactions, engagement, etc.) and an online or offline scoring pipeline.
A dark-themed dashboard showing a ranking panel with users (Maya Rao top with a score of 88, followed by John Marsh and Leo Abbas) and a "Your Notes" sidebar. At the bottom are small "Interviewer" and "You" icons.
  1. How quickly must a new post appear in followers’ feeds?
    • Example: “A few seconds is fine; it shouldn’t take minutes.”
  2. What is the target feed load latency?
    • Example: “The feed should load within 1 second on open.”
  3. Which content types should the feed support?
    • Example: “Text, images, and videos.”
  4. Is occasional duplication after refresh acceptable?
    • Example: “Yes — occasional duplicates after a refresh are acceptable.”
Scope for this example (explicitly state what we will design):
  • Users can follow other accounts.
  • Users create posts that include text, images, or videos.
  • The feed shows the newest posts only from accounts a user follows.
  • Feed must load within 1 second on open.
  • A new post should reach followers within a few seconds.
  • Occasional duplicate posts on refresh are acceptable.
Use this table to summarize functional and non-functional requirements:
A dark-themed UI mockup showing a smartphone screen with a progress bar reading "1.0 s" while the feed loads. On the right is a "Your Notes" list of numbered requirements, with "#3 THE FEED LOADS IN ONE SECOND" highlighted.
Step 2 — Back-of-the-envelope estimation Ask about scale: how many users, how often do they open the feed, how frequently do they post? Example assumptions below produce a realistic read-heavy workload and will guide architecture choices (caching, pre-computation, and fan-out). Assumptions
  • Daily active users (DAU): 10,000,000
  • Average opens per user per day: 5
  • Average posts per user per month: 3
Calculations
  • Feed reads/day = 10,000,000 × 5 = 50,000,000 reads/day
  • Seconds per day = 86,400 → reads/sec ≈ 50,000,000 / 86,400 ≈ 580 reads/sec
  • Total posts/month = 10,000,000 × 3 = 30,000,000 posts/month
  • Posts/day ≈ 30,000,000 / 30 ≈ 1,000,000 posts/day
  • Writes/sec ≈ 1,000,000 / 86,400 ≈ 12 writes/sec
  • Read : write ratio ≈ 580 : 12 ≈ 48 : 1 (≈ 50 reads per write)
Summarized in a table: These numbers show the system is read‑heavy. That should drive design decisions: favor low-latency read paths, caching, and pre-computation (fan-out strategies) over write-optimized designs.
A dark-themed slide estimating traffic for 10,000,000 daily users, showing read/write math (5 opens/day → 50,000,000 reads/day = 600 reads/sec; 3 posts/month → 1,000,000 writes/day = 12 writes/sec). The screen is labeled "Estimate" and highlights read/write rates.
The key takeaway from estimation: the feed is read-heavy. Prioritize fast read paths (caching and pre-computation/fan-out) and acceptable eventual consistency. Use the read/write ratio to justify design trade-offs during your interview.
Next steps in the six-step framework (not covered here) would include choosing a high-level architecture (push vs. pull fan-out), designing data models for posts and user relationships, defining storage and caching layers, and outlining operational concerns (monitoring, throttling, and backpressure). For reference and deeper study, consider these resources: Links and References

Watch Video