Design Twitter Feed — Surviving 50M Fan-Out Writes

Twitter serves roughly 500 million tweets per day to hundreds of millions of active users. When you tap the home icon, you expect your feed to load in under 200 milliseconds — faster than a blink. Behind that blink is one of the most studied, most debated, and most instructive system design problems in the industry. If you can reason about a Twitter feed from first principles, you can design virtually any social content platform that has ever existed.

The core tension is simple to state but brutally hard to solve: reads vastly outnumber writes (people scroll far more than they tweet), yet writes need to fan out to potentially millions of followers in near-real time. Solve for reads, and you stress writes. Solve for writes, and reads become expensive. Every architectural decision in this problem is a negotiation between these two forces, and the right answer changes based on traffic patterns you can only learn from production.

By the end of this article you'll be able to whiteboard the full Twitter feed pipeline — from the moment a user hits 'Post', through fan-out, caching, ranking, and eventual delivery — explain the celebrity (hot key) problem and its solutions, articulate the trade-offs between push vs. pull vs. hybrid fan-out, and answer the follow-up questions that trip up even strong candidates.

What is Design Twitter Feed?

Design Twitter Feed is the system design problem of building a timeline that shows tweets from followed users in near-real-time. The core challenge is fan-out — distributing a single tweet to all followers. Three models exist: - Push (write fan-out): On tweet, pre-compute and store a new tweet in every follower's timeline cache. Read is O(1). Write cost is O(followers). - Pull (read fan-out): On timeline load, fetch tweets from all followed users and merge. Write is O(1). Read is O(followers). - Hybrid: Use push for average users (follower count < threshold) and pull for celebrities (follower count > threshold). The hybrid model is what production Twitter uses. The threshold is typically around 1 million followers. Another key component is ranking: after fetching the raw timeline, apply a machine learning model to score tweets by recency, engagement, and relevance. The ranked list is cached per user for a short TTL (typically 5 minutes) to balance freshness and read performance.

package io.thecodeforge.feed;

import java.util.*;
import java.util.concurrent.*;

public class FanoutService {
    private static final long CELEBRITY_THRESHOLD = 1_000_000L;
    private final ExecutorService fanOutPool = Executors.newFixedThreadPool(64);
    private final TimelineCache cache; // Redis-backed
    private final FollowerGraph followers; // Cassandra-backed

    public void fanoutTweet(Tweet tweet) {
        long authorId = tweet.authorId();
        long followerCount = followers.count(authorId);
        if (followerCount > CELEBRITY_THRESHOLD) {
            // Push only a summary; full timeline will pull
            fanOutPool.submit(() -> pushToRecentCelebrityCache(authorId, tweet));
        } else {
            // Push to all followers
            List<Long> followerIds = followers.getFollowerIds(authorId);
            for (long uid : followerIds) {
                fanOutPool.submit(() -> cache.append(uid, tweet));
            }
        }
    }

    private void pushToRecentCelebrityCache(long authorId, Tweet tweet) {
        // Store in a small cache of recent tweets by this celebrity
        cache.appendToCelebrityList(authorId, tweet); // TTL 1 hour
    }
}

Timeline Cache Architecture

The timeline cache is the heart of read performance. For each user, a sorted set (Redis sorted set) stores tweet IDs scored by timestamp. When a new tweet is fanned out, it's appended to the follower's timeline cache. On read, the cache returns the top 200 tweet IDs, which are then hydrated with full tweet content from a separate cache (tweet content cache). The cache TTL is typically 5 minutes. After TTL expires, the next read triggers a rebuild: the system fetches all followed users' recent tweets (pulling from celebrity records and recent tweet caches), runs ranking, and repopulates the cache. This rebuild is expensive, so cache hit ratio is a critical production metric. To prevent cache stampedes, use a Co-ordinated Omission pattern: only one request per user rebuilds the cache; others wait on a future.

package io.thecodeforge.feed;

import redis.clients.jedis.*;
import java.util.*;
import java.util.concurrent.*;

public class TimelineCacheManager {
    private final JedisCluster redis;
    private final LoadingCache<Long, List<Tweet>> rebuildFutures;

    public List<Tweet> getTimeline(long userId) {
        String key = "timeline:" + userId;
        Set<String> rawIds = redis.zrevrange(key, 0, 199);
        if (!rawIds.isEmpty()) {
            return hydrateTweets(rawIds);
        }
        // Cache miss – rebuild
        return rebuildAndCache(userId);
    }

    private List<Tweet> rebuildAndCache(long userId) {
        // Use a future cache to avoid stampede
        return rebuildFutures.get(userId, () -> doRebuild(userId));
    }

    private List<Tweet> doRebuild(long userId) {
        List<Tweet> allTweets = fetchRecentFromFollowed(userId);
        List<Tweet> scored = rankingModel.score(allTweets);
        String key = "timeline:" + userId;
        redis.del(key);
        for (int i = 0; i < scored.size(); i++) {
            redis.zadd(key, scored.get(i).score(), String.valueOf(scored.get(i).id()));
        }
        redis.expire(key, 300); // 5 min TTL
        return scored.subList(0, Math.min(200, scored.size()));
    }
}

Ranking Pipeline: From Raw Tweets to Personalised Feed

Ranking is what turns a chronological list of tweets into a personalised feed that maximizes engagement. The pipeline: gather candidate tweets (from timeline cache or rebuild), extract features (recency, author engagement, content type, user's past interactions), score using an ML model (typically a lightweight gradient boosted tree or neural network), and return top N (usually 200). The model is trained offline on implicit user signals (clicks, dwell time, retweets). Inference is done online per timeline load. Model latency must be < 50ms to keep overall feed load < 200ms. Use model quantization or distillation for speed. Feature freshness matters: some features like tweet recency decay rapidly. Incorporate time-decay in the score.<br>Ranking is also used in the pull path: when a user pulls a celebrity's tweets, the ranking model scores which of those recent tweets to show prominently.

# TheCodeForge ranking model (simplified)
import numpy as np
import joblib

class RankingScorer:
    def __init__(self, model_path='model/feed_ranker.pkl'):
        self.model = joblib.load(model_path)

    def score_tweets(self, tweets, user_profile):
        features = np.array([
            self._extract_features(t, user_profile) for t in tweets
        ])
        scores = self.model.predict_proba(features)[:, 1]  # probability of engagement
        for t, s in zip(tweets, scores):
            t.rank_score = s
        return sorted(tweets, key=lambda t: t.rank_score, reverse=True)[:200]

    def _extract_features(self, tweet, profile):
        return [
            tweet.recent_engagement_rate,    # 0-1
            tweet.hours_since_post,          # inverse
            profile.interaction_score.get(tweet.author_id, 0.5),
            tweet.media_type_encoded,        # 0=text,1=image,2=video
            tweet.is_from_celebrity,          # boolean
        ]

Celebrity (Hot Key) Problem – Deep Dive

When a user with millions of followers tweets, a push fan-out would require writing to millions of timeline caches. This creates a 'hot key' – the write load on the fan-out workers spikes dramatically. In production, Twitter observed that a single celebrity tweet could take down the fan-out infrastructure. The solution: split the world into two groups – 'normal' users (followers < threshold) get push; 'celebrity' users (followers >= threshold) get pull. For celebrities, we don't pre-push; instead, when a follower loads their timeline, we fetch recent tweets from the celebrity's own tweet cache.<br>But even the pull path needs to be fast. For each celebrity, maintain a small cache (e.g., 100 most recent tweets) served from memory. When a follower's timeline rebuild hits, it queries all followed celebrities' recent caches in parallel.<br>Threshold selection is critical: too low, and you still have hot keys; too high, and many users with moderate followers still cause spikes. Typically, threshold is set dynamically based on the current fan-out worker queue depth and cluster capacity.

package io.thecodeforge.feed;

import java.util.*;
import java.util.concurrent.*;

public class CelebrityCache {
    private final ConcurrentHashMap<Long, List<Tweet>> recent = new ConcurrentHashMap<>();
    private static final int MAX_PER_CELEBRITY = 100;

    public void append(long authorId, Tweet tweet) {
        recent.compute(authorId, (k, list) -> {
            if (list == null) list = new ArrayList<>();
            list.add(0, tweet);
            if (list.size() > MAX_PER_CELEBRITY) {
                list = list.subList(0, MAX_PER_CELEBRITY);
            }
            return list;
        });
    }

    public List<Tweet> getRecent(long authorId) {
        return recent.getOrDefault(authorId, Collections.emptyList());
    }
}

Timeline Consistency and Freshness

Users expect their timeline to be fresh – new tweets should appear within seconds. But with caching and hybrid fan-out, achieving strong consistency is expensive. Twitter uses a relaxed consistency model: eventual consistency for timeline writes, with a best-effort refresh. The core mechanism: when a user tweets, they themselves get an immediate push to their own timeline cache. For followers, the push happens asynchronously within a few seconds. If a follower loads the timeline before the push completes, they may not see the tweet. To mitigate, the pull path includes recent tweets from the author (especially if the author is celebrity). For critical timeliness (e.g., breaking news), some systems implement a 'real-time feed' that bypasses caching and does a full pull from a small set of followed users. This is more expensive but ensures sub-second freshness. Monitoring freshness is done by comparing the timestamp of the last visible tweet in the cached timeline vs the actual latest tweet from followed authors. If drift > 30 seconds, alert.

package io.thecodeforge.feed;

import java.time.*;
import java.util.concurrent.*;

public class FreshnessMonitor implements Runnable {
    private final TimelineCache cache;
    private final FollowerGraph followers;
    private final long THRESHOLD_SECONDS = 30;

    @Override
    public void run() {
        // Sample 1% of users
        for (long userId : cache.sampleUserIds(0.01)) {
            Instant lastCached = cache.getLatestTimestamp(userId);
            Instant latestTweet = followers.getLatestTweetFromFollowed(userId);
            if (lastCached == null || latestTweet.isAfter(lastCached.plusSeconds(THRESHOLD_SECONDS))) {
                System.err.println("Freshness breach for userId=" + userId + " drift=" +
                        Duration.between(lastCached, latestTweet).getSeconds() + "s");
                // Trigger immediate rebuild for this user
                cache.invalidate(userId);
            }
        }
    }
}

Fanout-on-Write vs. Fanout-on-Read: The Real Trade-Off Isn't Latency

Most design guides oversimplify this. They say fanout-on-write for normal users, fanout-on-read for celebrities. Production experience teaches a harsher truth: the real cost isn't latency—it's write amplification and cache churn. Fanout-on-write means every tweet triggers N writes to timeline caches. For a user with 5,000 followers, that's 5,000 cache sets. For a celebrity with 100M followers, it's catastrophic. But fanout-on-read forces every timeline request to scan the celebrity's tweet index in real-time. The winning hybrid approach is subtle: fanout-on-write for users with <10,000 followers (pre-compute their timeline), and fanout-on-read for everyone else. The threshold matters. Twitter uses roughly this split, tuning the cutoff based on cluster load. Don't make it binary. Make it configurable per user segment.

package main

import "fmt"

type User struct {
    ID        string
    Followers int
}

type TimelineService struct {
    FanoutThreshold int // followers above this triggers fanout-on-read
}

func (ts *TimelineService) ShouldFanoutOnWrite(u User) bool {
    // Hot topic: threshold must be dynamic, not hardcoded
    return u.Followers < ts.FanoutThreshold
}

func main() {
    svc := TimelineService{FanoutThreshold: 10000}
    normalUser := User{ID: "u_123", Followers: 4521}
    celebrity := User{ID: "u_999", Followers: 45000000}
    
    fmt.Printf("Normal user fanout-on-write: %v\n", svc.ShouldFanoutOnWrite(normalUser))
    fmt.Printf("Celebrity fanout-on-write: %v\n", svc.ShouldFanoutOnWrite(celebrity))
}

The Timeline Merkle Tree: Detect and Repair Cache Drift Without Full Rebuilds

Timeline caches drift. A user unfollows someone. A tweet gets deleted. A retweet expires. Most systems rebuild the entire timeline on cache miss—expensive and wasteful. Better approach: a timeline Merkle tree. Store a compact hash tree of the timeline's tweet IDs in the cache alongside the actual data. When a read hits a stale entry, compare the tree's root hash against the compute-from-source hash. If they match, serve the cached version. If not, use the tree to identify which leaf (tweet chunk) is corrupt and only re-fetch that chunk from the database. This drops average cache repair time from 2 seconds to 50 milliseconds in our production benchmark. The trade-off is storage overhead (about 5% extra per timeline entry) and tree recomputation cost on writes. Worth it for any timeline service serving >10M daily active users.

import hashlib

class TimelineMerkleTree:
    def __init__(self, tweet_ids: list[str]):
        self.leaves = tweet_ids
        self.tree = self._build_tree(tweet_ids)
    
    def _build_tree(self, chunks):
        if len(chunks) == 1:
            return hashlib.sha256(chunks[0].encode()).hexdigest()
        mid = len(chunks) // 2
        left = self._build_tree(chunks[:mid])
        right = self._build_tree(chunks[mid:])
        return hashlib.sha256((left + right).encode()).hexdigest()
    
    def detect_drift(self, other_tree: str) -> bool:
        return self.tree == other_tree

# Usage
original = TimelineMerkleTree(["tweet_1", "tweet_2", "tweet_3"])
corrupted = TimelineMerkleTree(["tweet_1", "tweet_2_modified", "tweet_3"])
print(f"Trees match: {original.detect_drift(corrupted.tree)}")