Design a News Feed

Problem Statement#

"Design a news feed system. Users should be able to post content and see a feed of posts from people they follow."

That's it. One sentence. The rest is yours to figure out.

Requirements Gathering#

This is where the interview actually begins. A strong candidate doesn't start drawing boxes. They ask questions. Not to stall, but because the answers fundamentally change the design.

Here's how a good requirements conversation looks:

Candidate: "Is this a mutual follow system like Facebook friends, or one-directional like Twitter where I can follow someone who doesn't follow me back?"

Interviewer: "One-directional. Think Twitter or Instagram."

Candidate: "Should the feed be purely reverse-chronological, or ranked by relevance, engagement, relationship strength, that kind of thing?"

Interviewer: "Ranked. Recency matters but it's not the only signal."

Candidate: "What scale are we designing for? DAU ballpark?"

Interviewer: "500 million DAU. About 300 million new posts per day."

Candidate: "How fresh does the feed need to be? If someone I follow posts right now, how quickly should it appear on my feed?"

Interviewer: "Within a few seconds. Near real-time."

Candidate: "Are we handling celebrity accounts, people with tens of millions of followers? That changes the write architecture significantly."

Interviewer: "Yes, the system should handle that."

Candidate: "What types of content, text only, or images and videos too?"

Interviewer: "Text, images, links. No video for now."

Candidate: "Infinite scroll, so we need pagination. Any requirement on how far back the feed goes?"

Interviewer: "Show the last 500 posts or 7 days, whichever comes first."

Candidate: "Out of scope: Stories, Ads, content from people you don't follow, Explore and Reels-style recommendations?"

Interviewer: "Correct, out of scope. Just the social graph feed."

Functional and Non-Functional Requirements#

Functional Requirements#

1. Users can create posts (text, images, links)
2. Users can follow and unfollow other users
3. Users see a ranked feed of posts from people they follow
4. Feed supports infinite scroll with stable pagination
5. New posts appear in followers' feeds within a few seconds
6. Users can like and comment on posts

Non-Functional Requirements#

Out of scope: Stories, Ads, Explore/Recommendations, Video streaming, DMs

Capacity Estimates#

Work through the math. Don't just state the numbers.

Post creation:
  300M posts/day ÷ 86,400 sec = ~3,500 posts/sec

Feed reads (users check feed ~5x/day):
  500M DAU × 5 ÷ 86,400 = ~29,000 feed reads/sec

Fan-out volume (avg 300 followers per user):
  3,500 posts/sec × 300 followers = ~1,050,000 feed updates/sec

Storage (post metadata only, avg 1KB per post):
  300M × 1KB = 300GB/day

Feed cache (500 entries/user; a sorted-set entry is NOT 16 bytes):
  Raw data is ~16B (8B post_id + 8B score), but a Redis ZSET
  element carries skiplist + hashtable + SDS overhead ≈ 60-90B.
  500M users × 500 × ~80B = ~20TB Redis memory
  Across ~160 cluster nodes: ~125GB/node
  (This is why you cap at 500 and only fan out to ACTIVE users:
   the memory bill, not CPU, is the binding constraint.)

The fan-out number, roughly 1M updates/sec, is the number that should make you pause. That's the core challenge.

High-Level Design#

Two flows drive everything: writing a post and reading the feed. Keep them separate in your head.

Write path: Client → Load Balancer → Post Service → saves to Post DB → publishes event to Kafka → Fan-out Service consumes → looks up followers from Social Graph DB → writes post ID to each follower's feed in Redis.

Read path: Client → Load Balancer → Feed Service → reads post IDs from Redis feed cache → batch-fetches post content from Post Cache → returns assembled feed.

The key insight: reads never touch the Post DB directly. Feed reads are a Redis lookup followed by a batch cache fetch. The database is only involved in writes.

Deep Dives#

1. The Fan-out Problem: Push vs Pull vs Hybrid#

This is the central question of the entire interview. Get this right and you've won most of the points.

Fan-out on write (push model)

When User A posts, the fan-out service immediately writes that post ID into the Redis feed of every follower.

• Feed reads become O(1) Redis lookups, extremely fast
• No computation at read time
• Problem: a user with 10M followers posting means 10M Redis writes triggered synchronously. At 3,500 posts/sec from such users, the fan-out queue drowns.

Fan-out on read (pull model)

When a user opens their feed, the system queries recent posts from everyone they follow, merges and ranks them on the fly.

• One write per post regardless of follower count
• Problem: a user following 500 accounts means 500 database queries per feed load, then merge and rank. At 29,000 feed loads/sec this is catastrophic.

Hybrid approach (what Twitter and Instagram actually use)

Fan-out on write for regular users (followers below a threshold, e.g. 10,000). Fan-out on read for celebrities (followers above threshold).

At read time: merge the pre-computed feed from Redis (regular followees) with a real-time pull from celebrity accounts you follow.

if follower_count < CELEBRITY_THRESHOLD:
    # Push post_id to each follower's Redis sorted set
    fan_out_to_followers(post_id, followers)
else:
    # Store in celebrity post cache (shared, not per-follower)
    cache_celebrity_post(post_id, author_id)
    # Followers merge this at read time

Celebrity posts are cached in a shared sorted set keyed by celebrity:{user_id}, scored by post timestamp, not duplicated per follower. One cache entry serves all 10M followers. Extremely cache-efficient.

The score matters: at read time you merge celebrity posts into the same timeline as the pre-computed feed, so celebrity entries must carry a timestamp to sort and to respect the pagination cursor. (Post IDs are Snowflake IDs, so the timestamp is also recoverable from the ID itself, but storing it as the sorted-set score keeps the read path a single ranged query instead of a decode-and-sort.)

2. Feed Storage: Redis Sorted Sets#

The feed cache is not a simple list. It needs to support ordered retrieval (by timestamp or ranking score), cursor-based pagination, O(log N) inserts, and efficient trimming to keep only the last 500 entries.

Redis Sorted Set is exactly the right structure.

Key:    feed:{user_id}
Member: post_id
Score:  timestamp (unix milliseconds) OR ranking score (float)
Max:    500 entries per user (ZREMRANGEBYRANK trims older ones)

# Fan-out worker: add post to follower's feed
ZADD feed:user_123 1718000000000 post_abc
ZREMRANGEBYRANK feed:user_123 0 -501   # keep latest 500

# Feed read: latest 20 posts
ZREVRANGE feed:user_123 0 19 WITHSCORES

# Cursor pagination: posts older than cursor_score
ZREVRANGEBYSCORE feed:user_123 (cursor_score -inf LIMIT 0 20

The ( prefix on cursor_score means exclusive. The post at the cursor is not returned again.

3. Feed Ranking#

Reverse-chronological is the baseline. Real ranking uses multiple signals scored together.

Signals:

• Recency: newer posts score higher, with a decay curve rather than a hard cutoff
• Engagement velocity: posts getting lots of likes/comments in the first 5 minutes get a boost
• Affinity: posts from accounts you interact with frequently rank higher
• Content type affinity: if you engage more with images, image posts rank higher
• Diversity: penalize showing 5 consecutive posts from the same author

In interviews, you don't need to design the full ML model. Name the signals, describe the two-pass approach.

Two-pass ranking:

1. Write time (coarse): When inserting into the feed sorted set, compute a basic score using recency plus the author's engagement history. Store as the sorted set score.
2. Read time (fine): Pull 100-200 candidate posts from Redis, re-score them with fresh engagement signals (like counts updated in the last few minutes), return top 20.

This separates feed assembly (fast, Redis) from ranking (slightly slower, can be a separate service).

4. Pagination: Cursor vs OFFSET#

This one comes up in almost every interview. Know it cold.

OFFSET-based pagination (wrong at scale):

SELECT * FROM posts ORDER BY created_at DESC LIMIT 20 OFFSET 200;

Two problems:

1. The database scans and discards 200 rows on every request, O(N) cost per page
2. If new posts arrive between page 1 and page 2, posts shift positions and users see duplicates or miss posts

Cursor-based pagination (correct):

The cursor is the score (timestamp) of the last post the client received. Next page means posts with score less than the cursor.

GET /feed?limit=20&cursor=1718000000000

Server: ZREVRANGEBYSCORE feed:{user_id} (1718000000000 -inf LIMIT 0 20

Response: {
  posts: [...],
  next_cursor: "1717999000000",
  has_more: true
}

The client stores next_cursor and sends it with the next scroll event. No position shifting. No duplicate posts. O(log N) query cost.

5. Post Hydration#

The feed cache stores post IDs only, not the full post content. This is intentional.

Why not store full posts? The same post appears in potentially millions of feeds. When the like count updates (which happens constantly), you'd need to update millions of Redis entries. Instead:

1. Read 20 post IDs from feed:{user_id} sorted set
2. Batch-fetch post content from a Post Cache (Redis): MGET post:abc post:def ...
3. On cache miss, batch-fetch from Post DB
4. Fetch author profiles from a separate User Cache
5. Assemble and return

Post cache TTL: 24 hours. Hot posts naturally stay warm. Cold posts fall through to DB, which rarely happens.

Data Model#

-- Posts (Cassandra or Postgres, partitioned by author_id)
posts (
  post_id       BIGINT PRIMARY KEY,  -- Snowflake ID (time-ordered)
  author_id     BIGINT NOT NULL,
  content       TEXT,
  media_urls    JSONB,
  like_count    INT DEFAULT 0,
  comment_count INT DEFAULT 0,
  created_at    TIMESTAMPTZ DEFAULT NOW()
)
-- Index: (author_id, created_at DESC) for profile page + celebrity pull

-- Follows (Postgres, two indexes critical)
follows (
  follower_id   BIGINT,
  followee_id   BIGINT,
  created_at    TIMESTAMPTZ,
  PRIMARY KEY (follower_id, followee_id)
)
-- Index: (followee_id) for fan-out, "who follows this person?"
-- Index: (follower_id) for feed read, "who does this person follow?"

-- Feed Cache (Redis Sorted Set)
-- Key: feed:{user_id}
-- Member: post_id (string)
-- Score: created_at timestamp (float, milliseconds)
-- Max size: 500 entries, trim on insert

-- Celebrity Post Cache (Redis Sorted Set, shared across all followers)
-- Key: celebrity:{user_id}
-- Member: post_id (string)
-- Score: created_at timestamp (float, milliseconds), needed for merge + cursor
-- Max size: last 100 posts, trim on insert

API Design#

POST /api/v1/posts
Authorization: Bearer <token>
Body: { "content": "Hello world", "media_urls": [] }
Response 201: { "post_id": "...", "created_at": "..." }

---

GET /api/v1/feed?limit=20&cursor=<timestamp_ms>
Authorization: Bearer <token>
Response 200: {
  "posts": [
    {
      "id": "post_abc",
      "author": {
        "id": "user_123",
        "username": "alice",
        "avatar_url": "https://..."
      },
      "content": "Hello world",
      "media_urls": [],
      "like_count": 142,
      "is_liked_by_me": false,
      "created_at": "2026-06-07T10:00:00Z"
    }
  ],
  "next_cursor": "1718000000000",
  "has_more": true
}

Note: user_id is never sent by the client. Identity comes from the auth token and the server extracts it server-side. Sending user_id as a query param is a security mistake.

Failure Scenarios and Edge Cases#

Code#

Fan-out Worker#

public class FanoutWorker {
    private final RedisCluster redis;
    private final SocialGraphService graphService;
    private static final int CELEBRITY_THRESHOLD = 10_000;
    private static final int MAX_FEED_SIZE = 500;

    public void handlePostCreated(PostCreatedEvent event) {
        long authorFollowerCount = graphService.getFollowerCount(event.authorId());

        if (authorFollowerCount >= CELEBRITY_THRESHOLD) {
            // Celebrity path: store in shared sorted set, not per-follower.
            // Scored by timestamp so the read path can merge + paginate.
            String key = "celebrity:" + event.authorId();
            double score = event.createdAt().toEpochMilli();
            redis.zadd(key, score, event.postId());
            redis.zremrangeByRank(key, 0, -101); // keep last 100 posts
            return;
        }

        // Regular path: fan out to active followers only
        List<Long> followers = graphService.getActiveFollowers(
            event.authorId(),
            Duration.ofDays(7)
        );

        for (long followerId : followers) {
            String feedKey = "feed:" + followerId;
            double score = event.createdAt().toEpochMilli();

            redis.zadd(feedKey, score, event.postId());
            redis.zremrangeByRank(feedKey, 0, -(MAX_FEED_SIZE + 1));
        }
    }
}

Feed Read with Celebrity Merge and Cursor Pagination#

public FeedResponse getFeed(long userId, String cursor, int limit) {
    // Exclusive upper bound so the cursor post is never returned twice.
    String maxScore = cursor != null ? "(" + cursor : "+inf";

    // 1. Pre-computed feed page (cursor-bounded, scored).
    Set<Tuple> regularPosts = redis.zrevrangeByScoreWithScores(
        "feed:" + userId, maxScore, "-inf", 0, limit
    );

    // 2. Celebrity posts, also cursor-bounded and scored, so they merge
    //    into the same timeline instead of jumping to the top on every page.
    List<String> followedCelebrities = graphService.getFollowedCelebrities(userId);
    List<Tuple> celebrityPosts = new ArrayList<>();
    for (String celebId : followedCelebrities) {
        celebrityPosts.addAll(redis.zrevrangeByScoreWithScores(
            "celebrity:" + celebId, maxScore, "-inf", 0, limit
        ));
    }

    // 3. Merge by score (timestamp) and take the top `limit` candidates.
    List<ScoredId> page = mergeByScore(regularPosts, celebrityPosts, limit);

    // 4. Cursor + has_more come from the CANDIDATES, before hydration, so a
    //    deleted post filtered out below can't corrupt pagination.
    String nextCursor = page.isEmpty() ? null
        : String.valueOf(page.get(page.size() - 1).score());
    boolean hasMore = page.size() == limit;

    // 5. Batch hydrate; drop nulls (deleted posts) for display only.
    List<Post> posts = postCache.mget(page.stream().map(ScoredId::id).toList())
        .stream().filter(Objects::nonNull).collect(toList());

    return new FeedResponse(posts, nextCursor, hasMore);
}

Trade-off Summary#

Follow-up Questions#

Basic

Q: Why can't we just use OFFSET pagination?

When new posts arrive between page 1 and page 2, everything shifts. A post that was at position 20 is now at 21, so you either skip it or show it twice. OFFSET also requires the DB to scan and throw away all preceding rows on every request. Cursor uses the last-seen timestamp as an anchor so new posts don't affect older pages.

Q: Why store post IDs in the feed cache instead of full posts?

The same post appears in potentially millions of feeds. If like_count updates (which happens constantly), you'd need to update millions of cache entries. Storing only the ID means one source of truth for post content, updated in one place.

Q: What's the difference between the feed sorted set and the celebrity post list?

Feed sorted set is per-user, holds post IDs of people they follow (regular users only), scored by timestamp. Celebrity post list is per-celebrity, shared across all their followers, holds their last 100 posts. At read time both are merged.

Q: How does the fan-out service know who follows a celebrity?

It doesn't need to for the celebrity path. Celebrity posts skip fan-out entirely and are written to celebrity:{id}. The fan-out service only needs to look up followers for regular users, which is bounded by the threshold.

Minute-by-Minute Interview Playbook#

0 to 5 min: Requirements Ask the 6-7 questions above. Don't skip. The celebrity and scale questions directly determine your design. Confirm out-of-scope. Write FR/NFR on the board.

5 to 8 min: Capacity estimates Do the fan-out math out loud. The roughly 1M updates/sec number is what justifies the entire hybrid architecture. If you skip this, your design choices look arbitrary.

8 to 18 min: HLD Draw the two paths (write and read). Show Kafka between Post Service and Fan-out Service. This decouples post creation latency from fan-out latency. Show Redis as the primary feed read target.

18 to 38 min: Deep dives Lead with fan-out. Walk through push, explain why it breaks for celebrities, then pull, explain why it breaks at read scale, then hybrid. This single section is worth the most interview points. Then cover Redis sorted sets, cursor pagination, two-pass ranking. Move fast on things you know cold.

38 to 45 min: Failure scenarios and wrap-up Cover cold start and thundering herd if time allows. Summarize the trade-offs in one sentence: "We chose hybrid fan-out because neither pure approach scales alone here. Push collapses on write for celebrities, pull collapses on read for high-follow users."

Green flags

• Immediately frames fan-out as the core tension
• Proactively brings up celebrities before the interviewer asks
• Correctly identifies the celebrity threshold as a tunable parameter, not a magic number
• Explains cursor pagination by first describing why OFFSET breaks
• Distinguishes feed cache (post IDs) from post cache (full content)

Red flags

• Starts drawing boxes without asking about scale or follow topology
• Describes pure push or pure pull without the hybrid
• Uses OFFSET pagination
• Stores full post content in the feed sorted set
• Doesn't mention Kafka or any async decoupling between post creation and fan-out

Further Reading#