Design a News Feed: Architecture Diagram and Data Flow

Once you’ve agreed on requirements with your interviewer, the next step is drawing the architecture. This article walks through the components a strong candidate places on the whiteboard for a news feed system, how data flows between them, and why each component exists.

High-Level Components

A production-grade news feed architecture typically includes:

1. Client (mobile/web) — requests feed pages, renders posts, sends new posts/interactions.
2. API Gateway / Load Balancer — routes requests, handles auth, rate limiting.
3. Post Service — accepts new posts, writes to the post store, publishes a “new post” event.
4. Fanout Service — subscribes to new post events, determines the follower list, and writes feed entries into each follower’s precomputed timeline.
5. Timeline Service — reads precomputed feed entries (or does on-demand aggregation for high fan-out accounts) and assembles the response.
6. Ranking Service — scores and re-orders candidates before they’re returned to the client.
7. Graph Service — stores follow/friend relationships; queried by the fanout service to know who to push to.
8. Cache Layer (Redis/Memcached) — stores precomputed feeds and hot post metadata.
9. Post Store (Cassandra/DynamoDB-style wide column store) — durable storage for post content.
10. CDN — serves media (images, video) referenced by posts.

Publisher-Subscriber Pattern

The fanout problem is naturally modeled as pub-sub. When a user publishes a post:

1. Post Service writes the post to the Post Store and emits a PostCreated event onto a message queue (Kafka, Kinesis, or similar).
2. The Fanout Service consumes PostCreated events. It looks up the author’s follower list from the Graph Service.
3. For each follower (below a fanout threshold), it pushes the new post ID into that follower’s feed cache (a Redis sorted set keyed by user ID, scored by timestamp).
4. For high-follower accounts, the fanout service skips the push step entirely and instead tags the post for pull-time retrieval — this is the fanout-on-read escape hatch for the celebrity problem.

This decoupling is the reason pub-sub is preferred over a synchronous call chain: the Post Service returns to the client the instant the post is durably stored, and fanout happens asynchronously without blocking the publish latency the user experiences.

Timeline Service and Data Flow on Read

When a user opens the app:

1. Client sends GET /feed?cursor=... to the API Gateway.
2. Timeline Service checks the user’s feed cache (Redis sorted set of post IDs).
3. If populated (the common case for regular users), it hydrates post IDs into full post objects by batch-fetching from the Post Store or a post metadata cache.
4. If the user follows celebrity accounts, the Timeline Service performs a secondary on-demand query against those accounts’ recent posts and merges the two result sets by timestamp.
5. The merged candidate set is passed to the Ranking Service, which scores and reorders.
6. The final ordered list (paginated via cursor) is returned to the client.

Cache Warming

Cold caches are the single biggest latency risk in this architecture. Two mitigations worth naming in an interview:

• Warm on login: when a user’s session starts, proactively populate their feed cache in the background rather than waiting for the first feed request to trigger a cache-miss rebuild.
• Warm on fanout: since the fanout service is already writing to followers’ caches at post time, feeds for active users stay warm continuously — cache misses become rare edge cases (new followers, cache eviction, cold accounts).

A TTL-based eviction policy on the feed cache (e.g., 24-48 hours of rolling window) keeps memory bounded while ensuring active users almost never hit a cold cache.

Post Fanout in Detail

The fanout write itself deserves a data-flow diagram of its own:

PostCreated event
   -> Fanout Service reads follower_ids from Graph Service (paginated, batched)
   -> For each batch of N follower_ids:
        -> Redis pipeline: ZADD feed:{follower_id} {timestamp} {post_id}
   -> Emit FanoutComplete metric for monitoring

Batching and pipelining the Redis writes (rather than one round trip per follower) is what makes fanout economically viable even for accounts with tens of thousands of followers — this is a detail interviewers specifically listen for.

Putting the Diagram Together

A clean whiteboard flow for this question: Client → API Gateway → {Post Service, Timeline Service} → {Post Store, Graph Service, Cache Layer} ← Fanout Service (consuming from message queue) → Ranking Service → back to Client. Drawing the asynchronous fanout path as a dotted line separate from the synchronous read path makes the architecture’s decoupling immediately legible to the interviewer.

For candidates building a repeatable process for translating requirements into a clean architecture diagram across every system design question — not just feed — The 0-to-1 SWE Interview Playbook (Amazon: https://www.amazon.com/dp/B0H256Z1MF?tag=sirjohnnymai-20) covers the diagramming framework used throughout this series.

Summary

The architecture hinges on separating the synchronous write path (post creation) from the asynchronous fanout path (feed distribution), backed by a cache layer that absorbs the vast majority of read traffic. Getting this separation right on the whiteboard, and being able to narrate the data flow end to end, is what distinguishes a strong system design answer from a memorized diagram.