Design a News Feed: System Design Interview Walkthrough (2026)

When you sit down for a system design interview, the first thing the interviewer expects is a clear, structured conversation. For a news‑feed service—think of the timeline you see on a social platform—the discussion usually follows a pattern: requirements, API, high‑level design, deep dive on the tricky bits, and finally trade‑offs and follow‑ups. Below is a concrete walkthrough you can adapt on the fly.

1. Clarify Requirements

Functional

• Create post: Users can publish a short text, optional media, and tags.
• Follow/unfollow: Users subscribe to other users’ streams.
• Read timeline: Return a list of recent posts from accounts the user follows, ordered by recency or relevance.
• Like/comment: Basic engagement actions that may affect ranking.
• Personalization: Simple ranking based on recency and interaction history.

Non‑functional

• Latency: Read latency < 200 ms for a typical user; write latency < 100 ms.
• Throughput: Must handle a burst of writes during peak hours and a steady stream of reads.
• Scalability: System should grow from a few thousand users to millions without major rewrites.
• Availability: Aim for “five‑nines” read availability; writes can tolerate brief outages.
• Consistency: Eventual consistency is acceptable for timeline ordering; strong consistency needed for follow relationships.

Ask the interviewer which of these are in scope. Often they’ll narrow the focus to just the core timeline generation.

2. Define a Minimal API

POST /posts
  body: { userId, content, mediaUrl?, tags? }

POST /follow
  body: { followerId, followeeId }

GET /timeline?userId={id}&limit={n}&offset={m}
  response: [{ postId, authorId, content, timestamp, likes, comments }]

You can extend the API later (e.g., /like, /comment, /recommendations). Keeping the contract simple helps you focus on the architecture.

3. High‑Level Design Overview

+-----------+      +----------------+      +-----------------+
|   Client  | ---> | API Gateway    | ---> | Auth Service    |
+-----------+      +----------------+      +-----------------+
                         |                     |
                         v                     v
               +----------------+   +-------------------+
               | Write Service  |   | Follow Service    |
               +----------------+   +-------------------+
                         |                     |
                         v                     v
               +----------------+   +-------------------+
               | Post Store    |   | Follow Store      |
               +----------------+   +-------------------+
                         |                     |
                         v                     v
               +-------------------------------+
               | Timeline Service (Read Path) |
               +-------------------------------+
                         |
                         v
               +-------------------+
               | Timeline Store   |
               +-------------------+
                         |
                         v
               +-------------------+
               | Cache (Redis)    |
               +-------------------+

• API Gateway handles routing, rate‑limiting, and basic auth.
• Write Service validates posts and persists them to Post Store (e.g., a sharded relational DB or a document store).
• Follow Service maintains the follower graph in Follow Store (often a key‑value store for fast look‑ups).
• Timeline Service is the read side. It builds a per‑user timeline, either on‑the‑fly (fan‑out on read) or pre‑computed (fan‑out on write).
• Cache holds hot timelines for low latency.

4. Deep Dive: Fan‑Out Strategies

4.1 Fan‑Out on Write (Push Model)

• When a user posts, the system pushes the post ID to each follower’s timeline store.
• Pros: Read is O(1); low latency for the end user.
• Cons: Write cost scales with follower count; high‑profile users can cause spikes.
• Implementation tip: Use a message queue (e.g., Kafka) to stream the post to a worker pool that updates follower timelines in batches.

4.2 Fan‑Out on Read (Pull Model)

• Timeline Service reads the follower list, fetches recent posts from each followed user, merges, and sorts.
• Pros: Write cost constant; easy to handle celebrity users.
• Cons: Read latency grows with number of follows; caching becomes essential.
• Implementation tip: Store recent posts per user in a fast store (e.g., Cassandra) and merge in memory; cache the merged result for a short TTL.

4.3 Hybrid Approach

• For users with < 10 k followers, use push; for larger accounts, fall back to pull.
• This pattern matches what many large platforms employ and balances write/read load.

5. Storage Choices

Explain why you pick each store, emphasizing consistency guarantees and scaling properties.

6. Handling Ranking & Personalization

A simple ranking algorithm can be:

1. Filter posts from followed users within the last 24 h.
2. Score each post: score = α * recency + β * interactionScore.
3. Sort descending.

• Recency: Unix timestamp difference.
• InteractionScore: Derived from likes/comments the user previously gave to the author.

You can keep the scoring logic in the Timeline Service; later you could offload heavy ML models to a separate recommendation microservice.

7. Trade‑offs & Bottlenecks

Typical interview follow‑ups:

• How would you handle a user with millions of followers? → Explain the pull fallback and possibly a separate “celebrity” pipeline.
• What if the read latency spikes during a flash‑crowd event? → Discuss cache warm‑up, read‑through patterns, and fallback to a simplified timeline.
• How do you ensure data durability? → Replication in the chosen stores, write‑ahead logs, and idempotent workers.
• Can you add a “hide post” feature? → Store a per‑user hide list and filter it during timeline generation.
• What monitoring metrics would you expose? → Write latency, read latency, cache hit ratio, queue depth, and error rates.

8. Testing & Iteration (where Call Assistant helps)

During interview prep, you can use Call Assistant to rehearse your explanation:

1. Speak aloud while reading the design; the assistant captures key points and flags missing pieces.
2. Practice follow‑up answers; it can suggest concise pivots to keep the conversation on track.
3. Ground stories in your own experience by referencing past projects where you built a similar pipeline.

These practices tighten your narrative and reduce filler.

How to practice this

1. Sketch the diagram on paper without looking at any reference. Time yourself to stay under 5 minutes.
2. Run a mock interview with a peer or use Call Assistant to record your answer; review the transcript for gaps.
3. Iterate on trade‑offs: pick a different storage option or fan‑out strategy and explain the impact in a few sentences.

---

FAQ

Q: What’s the simplest way to start a news‑feed design in an interview? A: Begin with functional requirements, propose a minimal API, and choose a fan‑out strategy that matches the expected scale. Keep the rest of the architecture as high‑level blocks.

Q: How do I decide between a relational DB and a document store for posts? A: If posts have a fixed schema and you need strong ACID guarantees, a relational DB works. For flexible media metadata and rapid schema evolution, a document store is more pragmatic.

Q: Should I worry about eventual consistency for the timeline? A: Yes, but it’s acceptable for most feeds. Explain that a post may appear a few seconds later for some followers, which is a trade‑off for higher availability.

Q: What monitoring alerts are essential for a news‑feed service? A: Alert on read latency > 200 ms, write latency > 100 ms, cache miss ratio > 30 %, and queue backlog exceeding a threshold.

Q: How can I show depth without writing code? A: Walk through a concrete example: user A follows B and C, B posts at 10:00, C posts at 10:05; illustrate how the timeline service merges and scores these posts.