Design a News Feed: Scaling Bottlenecks

The bottleneck discussion is where senior candidates separate from mid-level ones. Anyone can draw a feed architecture; fewer candidates can proactively name the four or five ways it breaks at scale and propose concrete mitigations. This article covers the bottlenecks interviewers most commonly probe: the celebrity problem, hot partitions, cache stampede, and cross-region replication.

The Celebrity Problem (Fan-out Explosion)

This is the single most-asked follow-up on the news feed question. In a pure fanout-on-write model, a celebrity account with 50 million followers triggers 50 million individual cache writes the instant they post. Even with batched, pipelined Redis writes, this creates a massive, bursty write spike that can starve the fanout service’s capacity for every other (non-celebrity) post queued behind it.

Mitigations:

• Hybrid fanout: for accounts above a follower-count threshold (e.g., 1 million), skip write-time fanout entirely. Instead, tag the post and let it be retrieved via fanout-on-read at serve time, merged into followers’ feeds dynamically.
• Tiered thresholds: some systems use multiple tiers (regular, “influencer,” “celebrity”) with progressively more aggressive read-time merging as follower count increases, rather than a single hard cutoff.
• Dedicated fanout queue priority: even for the accounts that do get written to cache, isolate celebrity fanout jobs onto separate queue partitions so they don’t head-of-line block fanout for regular users.

Hot Partitions

Any system that partitions data by a key (user_id for feed cache, author_id for post lookups) risks hot partitions when the key distribution is skewed — which it always is on a social graph, because of the same celebrity effect.

• A shard holding a celebrity’s post data or a disproportionate share of their followers’ feed caches will see far higher QPS than an average shard, creating a straggler that slows down aggregate p99 latency even if the cluster’s average load looks healthy.
• Mitigation: consistent hashing with virtual nodes spreads load more evenly, but doesn’t fully solve skew from a single extremely hot key. For known celebrity accounts, apply key salting — split a single hot celebrity’s data across multiple sub-keys (post:{id}:shard0 through post:{id}:shard7) and fan reads out across the shards, recombining client-side or at an aggregation layer.
• Read replicas: for hot read keys (a viral post’s engagement counts, for example), add read replicas specifically scaled to that key’s traffic rather than uniformly scaling the whole cluster.

Cache Stampede

When a popular cache entry expires (TTL eviction) or a cold cache miss occurs for a high-traffic key, many concurrent requests can simultaneously fall through to the backing store, hammering it with duplicate rebuild work — this is the classic cache stampede / thundering herd problem.

For a feed system, this shows up when a large batch of feed cache entries expire around the same time (e.g., all entries created during a launch-day cache warm expiring together 24 hours later), or when a viral post’s metadata cache entry expires while millions of users are actively viewing it.

Mitigations:

• Jittered TTLs: instead of a fixed 24-hour TTL for every cache entry, add random jitter (e.g., 22-26 hours) so entries don’t all expire in the same instant.
• Request coalescing / locking: when a cache miss occurs, the first request acquires a short-lived lock and rebuilds the cache; concurrent requests for the same key wait briefly and read the freshly rebuilt value instead of independently hitting the backing store.
• Stale-while-revalidate: serve the slightly stale cached value immediately while asynchronously refreshing it in the background, rather than blocking the user-facing request on a synchronous rebuild.

Cross-Region Replication

For a global user base, a single-region deployment creates unacceptable latency for users far from the primary data center, and a single point of regional failure.

• Multi-region active-active: deploy the feed cache and post store across multiple regions, with each region serving local read traffic from a nearby replica.
• Replication lag: since posts and fanout writes originate in one region, other regions see a propagation delay (typically tens to hundreds of milliseconds, occasionally seconds under load). This is acceptable for a feed system given the already-stated eventual consistency requirement — a post appearing a few hundred milliseconds later in a follower’s non-origin region is not user-visible in practice.
• Write locality: route a user’s writes (posts, likes) to their home region to minimize write latency, while reads can be served from whichever region is geographically closest, accepting the replication lag tradeoff.
• Conflict resolution: for feed data specifically, conflicts are rare because feed cache entries are append-only (new post IDs added, not concurrently edited) — this significantly simplifies cross-region replication compared to systems requiring true multi-master conflict resolution.

Bringing It Together

A senior-level answer connects these four bottlenecks back to the earlier capacity estimates: the celebrity problem is a direct consequence of the fanout-write volume calculated during estimation; hot partitions and cache stampede are consequences of the skewed access pattern inherent to a social graph; and cross-region replication is a consequence of scaling a single-region design to a global DAU number. Naming these connections explicitly — rather than treating bottlenecks as a disconnected checklist — is what interviewers are listening for at the staff/senior level.

For a complete walkthrough of how these scaling patterns recur across other high-frequency system design questions (URL shortener, chat system, rate limiter), The 0-to-1 SWE Interview Playbook (Amazon: https://www.amazon.com/dp/B0H256Z1MF?tag=sirjohnnymai-20) maps the same four bottleneck categories onto every major question in the standard interview loop.

Final Checklist

• Name the celebrity problem before being asked.
• Propose a hybrid fanout threshold with a specific mechanism, not just “handle it specially.”
• Mention jittered TTLs and request coalescing for cache stampede, not just “add more cache.”
• Acknowledge replication lag explicitly and justify why eventual consistency is acceptable for this specific system.

These four bottlenecks appear, in some form, across nearly every large-scale system design question in 2026 interview loops — mastering them here pays off well beyond the news feed question itself.