Twitter Feed — Hybrid Push+Pull (Whale-Aware)

The hybrid push+pull architecture is the production-grade solution to the Twitter feed problem that solves the 'whale problem' — the fundamental limitation of pure fanout-on-write. When a celebrity with 50 million followers posts a tweet, pure fanout-on-write triggers 50 million Redis cache writes, creating a minutes-long backlog that delays feed updates for all users. The hybrid approach eliminates this by treating high-follower users differently from regular users.

The key insight is that follower count follows a power-law distribution. The vast majority of users (99%+) have fewer than 100,000 followers, and for these users, fanout-on-write works perfectly — the fanout cost is bounded and completes in seconds. Only a tiny fraction of users (~0.1%) are 'whales' with 100,000+ followers, but these whales would generate 90%+ of the fanout work in a pure push model. The hybrid approach handles each group with the strategy that works best for them.

Normal users (< 100K followers) use fanout-on-write: their tweets are pushed to followers' cached feeds via Kafka workers, exactly as in the standard approach. Feed reads for followers of only normal users are a single Redis LRANGE — O(1) at ~2ms. Whale users (>= 100K followers) skip fanout entirely: their tweets are written to a dedicated WhaleCache (Redis). At feed read time, the FeedReader merges the user's pre-computed feed (FeedCache, containing non-whale tweets) with recent tweets from whales the user follows (WhaleCache). This merge adds ~5ms to the read path but eliminates the catastrophic write amplification.

The numbers make the case compelling. A whale with 50M followers posting a tweet: in pure push, 50M Redis writes taking 250 seconds; in hybrid, 1 WhaleCache write taking 2ms. The read-side cost of the hybrid merge is small: an average user follows ~5 whales, so the merge adds 5 cache lookups (~2ms) plus a sort merge (~2ms) — negligible compared to the eliminated 250-second fanout storm.

The whale threshold (100K followers in this template) is a tunable parameter. Setting it lower reduces write amplification further but increases the number of whale cache lookups on the read path. Setting it higher reduces read-side merge work but allows larger fanout storms. The optimal threshold depends on the follower distribution, feed read frequency, and infrastructure capacity. In practice, Twitter and similar platforms set the threshold between 10K and 500K followers.

This is the architecture interviewers expect senior candidates to arrive at after discussing the naive and fanout-on-write approaches. The progression from pull to push to hybrid demonstrates deepening understanding of the cost trade-offs. Candidates who can articulate the whale problem, propose the hybrid solution, and reason about the threshold tuning stand out in system design interviews at Twitter/X, Meta, Threads, and other social platforms.

The hybrid system uses 11 components organized into a CQRS-lite architecture with whale-aware routing on both the read and write paths. The key additions over the pure fanout-on-write variant are the WhaleCache (dedicated Redis for whale tweets) and the whale classification logic in TweetWriter.

The read path has three data sources instead of two. FeedReader executes two parallel cache reads: (1) LRANGE on FeedCache for the user's pre-computed non-whale feed, and (2) MGET on WhaleCache for recent tweets from each whale the user follows. It then merges the two sorted lists by timestamp — a standard sorted-array merge in O(K) where K is the total tweet count. On FeedCache miss, it falls back to TweetStore (DynamoDB) to reconstruct the non-whale portion. WhaleCache lookups happen regardless of FeedCache hit/miss status because whale tweets are never stored in FeedCache.

The write path includes whale classification. When TweetWriter receives a new tweet, it persists to TweetStore (DynamoDB — all tweets, both normal and whale). Then it checks the author's follower count. If the author has fewer than 100K followers (normal user), TweetWriter publishes a tweet_created event to FanoutStream (Kafka) for async fanout to FeedCache. If the author has 100K or more followers (whale), TweetWriter writes the tweet directly to WhaleCache (Redis SET) — no Kafka event, no fanout. This is the critical optimization: whale tweets bypass the entire fanout pipeline.

The FanoutWorker pool is smaller than in the pure push variant (40 workers vs 80). With whales excluded, the maximum fanout per event is capped at 100K cache writes (the whale threshold). The 95th percentile is much lower — most users have fewer than 1,000 followers. The reduced worker pool saves infrastructure cost while providing ample capacity for normal-user fanout.

WhaleCache is a small, hot Redis cluster. With approximately 1,000 whale users and 200 recent tweets each, the cache holds ~200K keys consuming ~500MB of memory. The hit rate is ~99% because whale tweets are extremely hot — read by millions of followers. Each whale's recent tweets are stored under a key pattern whale:{user_id} and refreshed on every whale tweet post with a 300s TTL.

FeedCache stores pre-computed feeds for all users, but containing only non-whale tweet IDs. This is the same structure as the pure push variant: feed:{user_id} with up to 200 tweet IDs. The 90% hit rate is slightly lower than the pure push variant's 92% because whale tweets are excluded — some feeds that were previously warm (kept alive by frequent whale tweets) now require WhaleCache augmentation.

The TweetStore (DynamoDB) persists all tweets from both normal and whale users. It includes an is_whale boolean flag indicating the author's classification at write time. This supports cache miss reconstruction: when FeedReader rebuilds a feed from TweetStore, it can filter out whale tweets (which should come from WhaleCache instead).