Choosing Between Push and Pull Models for High-Scale Social Feed Generation

The Feed Latency Dilemma

When scaling a social feed to millions of concurrent users, the primary engineering challenge is the trade-off between write-time computation and read-time latency. If you calculate a user's feed at the moment they open the app (Pull), the read request becomes computationally expensive. If you pre-calculate the feed when a post is created (Push), you shift the burden to the write operation, potentially creating massive write amplification.

The goal is to minimize the Time to First Byte (TTFB) for the end user while ensuring the system doesn't collapse during viral events where a single account triggers millions of updates.

Comparing Feed Delivery Strategies

Most high-scale systems, including the architecture used by LinkedIn for derived data, must choose between these two fundamental patterns based on the user's social graph density.

Metric	Push Model (Fan-out)	Pull Model (On-Demand)
Read Latency	Very Low (Read from cache)	High (Aggregate from multiple sources)
Write Latency	High (Update all followers)	Low (Single write to DB)
Storage Cost	High (Redundant copies per user)	Low (Single source of truth)
Consistency	Eventual	Stronger/Immediate

Engineering Trade-offs and Constraints

Write Amplification

In a Push model, a user with 100,000 followers creates a "write amplification" event. A single post results in 100,000 writes to individual user feed caches. This can saturate the event bus (e.g., Apache Kafka) and cause significant lag in feed updates.

The "Celebrity" Problem

Consistent hashing is often used to distribute data across clusters to avoid hotspots, but it cannot solve the problem of a single high-profile member. If a celebrity posts, pushing that update to millions of caches is inefficient. The practical engineering decision is often a Hybrid Approach: push for standard users and pull for high-follower accounts.

Eventual Consistency

Using distributed stores like Venice for derived data means accepting eventual consistency. A user might see a post in their feed (pushed cache) but find it missing if they immediately navigate to the author's profile (read from the primary store). This discrepancy is the cost of maintaining high availability across global data centers.

Implementing a Hybrid Feed Logic

To implement this, the system must categorize users based on their follower count. The following logic represents a high-level decision flow for a feed service.

// Pseudocode for Feed Delivery Logic
async function getFeedForUser(userId) {
  // 1. Attempt to fetch pre-calculated feed from distributed cache (Venice/Redis)
  let cachedFeed = await cacheStore.get(`feed:${userId}`);
  
  if (cachedFeed) {
    return cachedFeed;
  }

  // 2. Fallback: Pull from the social graph for users with no cache
  // or to supplement the cache with 'Celebrity' posts
  const following = await graphService.getFollowing(userId);
  const celebrityPosts = await postService.getRecentPostsFrom(following.filter(u => u.isCelebrity));
  
  return mergeAndSort(cachedFeed || [], celebrityPosts);
}

Validation and Monitoring

To verify if your distribution strategy is working, monitor the following metrics:

• Cache Hit Ratio: Percentage of feed requests served by the Push cache without hitting the primary database.
• Fan-out Lag: The time delta between a post being created and it appearing in the last follower's cache.
• Read Latency P99: Ensure that the Pull fallback for celebrities does not push the 99th percentile latency above your acceptable threshold (e.g., 200ms).

Limitations

This hybrid model increases architectural complexity. You now maintain two separate code paths for data retrieval and must synchronize the "celebrity" status of users in real-time to prevent the Push system from being overwhelmed as a user grows in popularity.