Solving the Celebrity Problem: Choosing Between Push and Pull Fan-out for Real-Time Feeds

The Latency Trade-off in Feed Delivery

When building a real-time feed, the primary challenge is the "Fan-out"—the process of delivering a single piece of content to millions of unique users. If you choose a pure push model, a single post from a user with 50 million followers triggers 50 million write operations, creating a massive latency spike known as the "Celebrity Problem." Conversely, a pure pull model forces the system to query and merge data from thousands of sources every time a user refreshes their page, leading to slow load times.

The goal is to maintain sub-second timeline delivery regardless of whether the content creator has ten followers or ten million.

Comparing Fan-out Strategies

The choice depends on the ratio of writes to reads and the distribution of follower counts across your user base.

Metric	Fan-out-on-Write (Push)	Fan-out-on-Load (Pull)
Write Latency	High (Write amplification)	Low (Single write)
Read Latency	Very Low (Read from cache)	High (Aggregation on request)
Storage Cost	High (Redundant copies)	Low (Single source of truth)
Best For	Standard users / Small audiences	Celebrities / Massive audiences

The Hybrid Architecture Decision

To avoid the pitfalls of both extremes, a hybrid approach is used. This involves categorizing users based on their follower count (e.g., a threshold of 10,000 followers) and applying different delivery logic based on that status.

Push Logic for Standard Users

For the majority of users, the system uses Fan-out-on-Write. When a standard user posts, the system identifies all their followers and injects the tweet ID into each follower's pre-computed timeline cache (typically an in-memory store like Redis). This shifts the computational burden to the write phase, ensuring that when a follower opens their app, the feed is already waiting for them.

Pull Logic for High-Follower Accounts

For "celebrity" accounts, the system bypasses the fan-out process entirely. The tweet is written once to the celebrity's own timeline. When a follower requests their feed, the system performs a Fan-out-on-Load: it fetches the pre-computed timeline of standard users and merges it in real-time with the tweets from the few high-follower accounts the user follows.

Implementation Logic

The following logic represents how a feed service decides which data to fetch during a read request. This should be executed within the Feed Aggregator service with read permissions to the User Cache and the Timeline Cache.

// Pseudo-logic for Timeline Aggregation
async function getTimeline(userId) {
  // 1. Fetch the pre-computed timeline (contains push-delivered tweets)
  const cachedTimeline = await redis.get(`timeline:${userId}`);

  // 2. Identify 'celebrity' accounts the user follows
  const followedCelebrities = await userGraph.getCelebrityFollows(userId);

  // 3. Pull latest tweets from those celebrities (Fan-out-on-Load)
  const celebrityTweets = await Promise.all(
    followedCelebrities.map(celebId => db.getLatestTweets(celebId))
  );

  // 4. Merge and sort by timestamp
  return mergeAndSort(cachedTimeline, celebrityTweets.flat());
}

Verification and Limitations

To verify the effectiveness of this hybrid model, monitor the P99 write latency during a high-profile event. If the write latency spikes when a celebrity posts, it indicates that the system is incorrectly attempting to "push" that content to millions of caches.

Limitations:

• Complexity: The system must now maintain a dynamic list of who is considered a "celebrity," as users may cross the threshold frequently.
• Merge Overhead: If a user follows too many celebrity accounts, the read-time merge operation becomes a bottleneck.

Rollback Strategy

If the hybrid logic causes consistency issues (e.g., celebrity tweets not appearing), revert the Feed Aggregator to a pure Pull model. This will increase read latency across the board but ensures data consistency while the merge logic is debugged.