News Feed for Social Media — System Design Walkthrough

The problem

You are designing the backend for a Facebook-like social media platform's news feed. Users log in to see a personalized feed of recent posts from their friends, which updates in near real-time as friends post new content. The platform is growing rapidly, and the feed must remain responsive even as the user base expands.

You are the backend engineer tasked with architecting the news feed system.

If the design is wrong, users will see stale or missing posts, experience slow load times, or the system could become unavailable during peak hours.

Must hold true

Feed must show the 20 most recent posts from a user's friends.
Updates should appear in the feed within 10 seconds of posting.
System should support 10 million daily active users.
Each post is under 1 KB in size.

Functional Requirements

What the system must DO.

Requirement	Priority
Users must be able to fetch the 20 most recent posts from their friends.	Must have
New posts from friends should appear in a user's feed within 10 seconds.	Must have
Users must be able to create new posts visible to their friends.	Must have
Users should be able to paginate older posts in their feed.	Nice to have

Non-Functional Requirements

How well it must do it — latency, availability, scale. Measurable, not vibes.

Requirement	Priority
The system must support 10 million daily active users with peak loads of 200,000 concurrent users.	Must have
Feed fetch requests should respond in under 500 milliseconds.	Must have
System availability should be at least 99.9%.	Nice to have

What you learn by asking

In an interview these facts are NOT volunteered — the candidate earns them with clarifying questions. These are the answers behind this design.

If you ask about…	The answer
average posts per user per day	Each user creates an average of 2 posts per day.
average number of friends per user	Each user has an average of 150 friends.
peak QPS for feed fetches	At peak, the system receives 40,000 feed fetch requests per second.
post size	Each post is approximately 1 KB.
daily active users	There are 10 million daily active users.
storage retention	Posts are retained for 1 year.

Capacity Estimation

Rough arithmetic turns the requirements into engineering decisions — it tells you which parts need scaling machinery and which are trivially easy. Only the order of magnitude matters.

Quantity	Answer	How it is derived
Total posts created per day	~20M posts/day	10 million users × 2 posts/user/day = 20 million posts/day
Peak feed fetch bandwidth	~800 MB/s	40,000 feed fetches/sec × 20 posts/fetch × 1 KB/post = 800,000 KB/sec = 800 MB/sec
Total storage required for 1 year of posts	~7.3 TB	20 million posts/day × 365 days × 1 KB = 7,300,000,000 KB ≈ 7.3 TB

The architecture, one version at a time

Nobody designs the final diagram in one stroke. Strong candidates start with the simplest thing that works, then let the numbers break it: each version fixes exactly one bottleneck with exactly one new component.

At each break you get a chance to call the fix yourself before it is revealed. You can stop reading after any version and still hold a complete, working system in your head — that is the point.

v1 — basic feed with direct DB access

Start with a simple design: client requests routed to a backend service, which reads/writes directly from a single database.

The simplest system has the client send requests to an API gateway, which forwards them to the feed service. The feed service fetches posts for the user's friends directly from the database. Post creation is handled by a post service writing to the same database.

This version works for small scale and demonstrates the core data flow, but will not scale to millions of users or low-latency requirements.

v1 — basic feed with direct DB access — the picture

Where v1 breaks

At 40,000 feed fetches/sec, every request hitting the database causes high latency and overload.

Quick check

Which single component would you add to fix that?

v2 — database can't handle peak read load

The fix: Add a cache — a small, very fast memory holding the most recently requested feeds — in front of the database for the feed service.

Caching is the standard solution when read requests vastly outnumber writes. The feed service first checks the cache for a user's feed; if present, it returns quickly. If not, it fetches from the database and populates the cache.

This greatly reduces database load and improves feed fetch latency, at the cost of cache invalidation complexity.

The finished design

The full reference design, with the reason behind every connection. When you practice, you will rebuild this from a palette that includes decoys.

Why each connection exists

Client AppAPI GatewayClients send requests to a single entry point for routing and security.
API GatewayFeed ServiceFeed requests are routed to the feed logic.
API GatewayPost ServicePost creation is handled by a dedicated service.
Feed ServiceFeed CacheFeed service checks cache for fast retrieval.
Feed ServiceDatabaseIf not in cache, fetch from database.
Post ServiceDatabasePosts must be persisted for durability.
Post ServiceFeed ServiceNew posts trigger feed updates for friends.

The design in one glance

Each version fixed exactly one problem. If you can retell this table from memory, you can derive the whole architecture on a whiteboard.

Version	What broke	The fix
v1 — basic feed with direct DB access	— the starting point	Start with a simple design: client requests routed to a backend service, which reads/writes directly from a single database.
v2 — database can't handle peak read load	At 40,000 feed fetches/sec, every request hitting the database causes high latency and overload.	Add a cache — a small, very fast memory holding the most recently requested feeds — in front of the database for the feed service.

API Design

Every operation traces back to a requirement — nothing extra, nothing missing.

Endpoint	Purpose
GET /feed	Fetch the 20 most recent posts from a user's friends.
POST /post	Create a new post visible to the user's friends.
GET /feed?page={n}	Fetch older posts from the user's feed.

Data Model

Entity	Fields
User	user_id: string (Unique user identifier), name: string (User's display name)
Post	post_id: string (Unique post identifier), author_id: string (User ID of the post creator), content: string (Text or media content), created_at: timestamp (Time of post creation)
FeedEntry	user_id: string (Feed owner), post_id: string (ID of post in feed), added_at: timestamp (When post appeared in feed)

Defending the Design

Interviewers close by stress-testing the design. Strong answers follow one shape: which component → what breaks there → the fix and its cost. Here are this problem's probes and the points a strong answer hits:

What happens if the feed cache becomes a bottleneck, and how can you address it? Cache overload can increase latency and cause more DB reads. Sharding or partitioning the cache by user/feed. Scaling cache horizontally (adding more nodes). Fallback to DB must be efficient.

If a user reports their feed is missing a friend's new post, what parts of your design could be responsible? Feed cache may be stale or not updated promptly. Feed service may not have received post-service notification. Database write may have failed or been delayed. Race conditions or propagation delays between post and feed update.

How would you scale the database to handle 20 million new posts per day and high read traffic? Partitioning or sharding the database by user or post ID. Read replicas to handle feed fetches. Efficient indexing on post timestamps and user relationships. Archiving or purging old posts if needed.

Discuss the trade-offs between push-based and pull-based feed update strategies in your design. Push ensures fast feed updates but higher write amplification and complexity. Pull is simpler but may show stale feeds and increase read load. Push is better for small, active friend graphs; pull scales better for large graphs. Hybrid approaches can balance freshness and efficiency.

Tip — Key takeaway

A scalable news feed system balances read efficiency, write throughput, and data freshness. Caching and decoupling feed generation from post creation are key to meeting latency and scale requirements. Each added component must address a concrete bottleneck, not just add complexity.

Common trap — Common mistakes on this problem

Relying solely on the database for every feed fetch, causing high latency and DB overload. · Using a queue for synchronous feed updates, which adds unnecessary delay and complexity. · Adding a search index for feed retrieval, when a simple key lookup or cache suffices.

You've seen the whole design — now build it yourself

The practice run walks the same steps, but YOU do the work: gather the requirements, run the numbers, wire the architecture — with an AI interviewer and per-step feedback.