Interview Prompt
Design a personalized feed where users can post updates and see recent relevant posts from people or topics they follow.
Frames the problem as a read/write fanout and ranking tradeoff.
Handles celebrity accounts and skewed follower distributions.
Separates candidate generation, ranking, and feed serving.
Mentions privacy checks, block lists, freshness, and backfill.
Step 1
Clarify functional and non-functional requirements first.
Functional Requirements
- Users can create posts with text and media references.
- Users can follow accounts or topics.
- The home feed returns a ranked list of recent posts.
- The system supports likes, comments, hides, blocks, and reports.
- Users should not see content they are not authorized to view.
Non-Functional Requirements
- Feed reads should be low latency, ideally under 200 ms p95.
- Posting should be reliable but can take seconds to propagate to all followers.
- The system should tolerate hot users with millions of followers.
- Ranking should be changeable without rewriting the whole serving system.
- Privacy and delete actions must take effect quickly.
Scale Assumptions
- 50 million daily active users.
- 10 million posts per day.
- Each user reads 20 feed pages per day.
- Average user follows 300 accounts, but some accounts have tens of millions of followers.
Feed reads
~11,500/sec average
50M users times 20 reads per day, with much higher peak during local evenings.
Post writes
~115/sec average
Posting QPS is much lower than feed read QPS, but fanout amplifies write work.
Fanout work
Potentially billions/day
A single celebrity post can create millions of feed insertions.
Feed cache
Hundreds of GB to TB
Precomputed feed IDs are compact but large at tens of millions of active users.
Step 2
Identify the key entities before picking storage.
| Entity | Fields and Relationships | Interview Notes |
|---|---|---|
| Post | post_id, author_id, body, media_refs, visibility, created_at, deleted_at | Canonical source of truth. Feed stores should reference post IDs. |
| FollowEdge | follower_id, followee_id, created_at, state | Shard by follower for reads and by followee for fanout queries or maintain two indexes. |
| HomeTimeline | user_id, ranked_post_id, score, inserted_at | Precomputed candidate list for active users. |
| Interaction | user_id, post_id, action, timestamp | Powers ranking, moderation, and analytics. |
Step 3
Define the APIs around the user flows.
| Interface | Request / Response | Contract Notes |
|---|---|---|
| POST /v1/posts | { text, mediaIds, visibility } -> { postId } | Writes canonical post data and publishes fanout events. |
| GET /v1/feed?cursor=... | Returns ranked post cards plus pagination cursor | Cursor should encode ranking position or timestamp boundary, not just page number. |
| POST /v1/follows | { targetId } | May require feed backfill for the newly followed account. |
| POST /v1/feed/events | { postId, action } | Captures likes, hides, dwell time, and negative feedback for ranking. |
Step 4
Trace the critical data flow step by step.
Post ingest
Post service writes the canonical post and publishes an event with author, visibility, and media metadata.
Fanout planner
Classifies the author as normal or high-follower. Normal users fan out on write; high-follower accounts fan out on read.
Candidate store
Stores precomputed candidate post IDs per user in a timeline cache or wide-column store.
Ranking service
Scores candidates using freshness, affinity, engagement predictions, content quality, and negative feedback.
Feed API
Fetches candidates, hydrates post cards, applies privacy filters, ranks, and returns a stable cursor.
Step 5
Convert the flow into a high-level design.
Final Design
News Feed final architecture
Serving Layer
Start with clients, routing, APIs, and the main synchronous path users depend on for this problem.
State Layer
Anchor the design around the key entities: Post, FollowEdge, HomeTimeline, Interaction.
Async Layer
Move slow, high-volume, or failure-prone work behind queues, workers, streams, caches, or background reconciliation.
Step 6
Deep dives interviewers are likely to probe.
Fanout on write vs fanout on read
- Fanout on write gives fast feed reads for normal accounts.
- Fanout on read avoids massive writes for celebrities but makes reads more expensive.
- A hybrid model is usually the strongest interview answer.
Ranking and freshness
- Candidate generation should keep enough recent inventory for ranking to work.
- Ranking can run in stages: cheap pre-rank first, expensive model on a smaller set.
- Track reasons for ranking decisions so debugging and policy enforcement are possible.
Privacy and deletes
- Apply privacy at serving time even if fanout happened earlier.
- Deletes need tombstones or invalidation so stale cached timelines do not leak posts.
- Blocks and muted accounts should be checked during hydration or final filtering.
Step 7
Tradeoffs to explain out loud.
Precompute full feed vs compute on demand
Use When
Precompute for active users when low latency is more important than perfect freshness.
Watch Out
Precomputing for inactive users wastes storage and fanout work.
Chronological feed vs ranked feed
Use When
Chronological is easier, transparent, and works for smaller networks.
Watch Out
Large networks need ranking to avoid overwhelming users with low-quality content.
Store post IDs vs hydrated cards in timeline
Use When
Store IDs to avoid duplicating large post data and to respect edits/deletes.
Watch Out
Hydration adds read-time latency and needs batching.
Avoid
Common mistakes that weaken the answer.
- Fanout on write to every follower without handling celebrity accounts.
- Ranking before checking privacy, blocks, or deletes.
- Using offset pagination for a feed that changes while the user scrolls.
- Ignoring cold-start users and newly followed accounts.
- Treating media processing as part of the synchronous post request.
Step 8
Follow-up questions with strong answers.
How do you handle a user with 100 million followers?
Do not fan out to every follower synchronously. Mark the account as high-follower, include its posts during read-time candidate generation, and cache ranked results for active followers.
How do you make deletes take effect quickly?
Write a tombstone, invalidate hot caches, filter deleted IDs during hydration, and run asynchronous cleanup for timeline stores.
How would you support both Following and For You feeds?
Use the same serving pipeline but change candidate sources and ranking features. Following is graph-heavy; For You adds content-based and collaborative candidates.
Step 9
What a strong answer should signal.
Architecture
Proposes a hybrid fanout design with separate candidate, ranking, and hydration stages.
Scale
Handles skew from celebrity users and high read volume.
Correctness
Maintains privacy, delete, block, and mute guarantees at serving time.
Product depth
Discusses freshness, ranking quality, feedback loops, and cold start.
Practice this problem under interview conditions.
Read the guide, then run the prompt live with LeetSys so you can practice requirements, key entities, API design, data flow, whiteboarding, tradeoff narration, and follow-up handling.
Related Guides
Mid-Level
Search Autocomplete
A system design interview guide for typeahead search suggestions with tries, prefix indexes, ranking, freshness, personalization, and abuse filtering.
Mid-Level
URL Shortener
A practical system design interview guide for building a URL shortener with redirects, custom aliases, analytics, rate limits, and high availability.
Senior
Video Streaming
A senior-level guide to designing a YouTube-style video streaming system with uploads, transcoding, CDN delivery, metadata, search, and recommendations.