Re-evaluating Fan-Out-on-Write vs. Fan-Out-on-Read Under Celebrity Traffic Spikes (2025)

Introduction

Modern social platforms and live-streaming services face unprecedented scale. When a celebrity with tens of millions of followers posts an update or goes live, the surge in traffic (“celebrity traffic spike”) can stress even the best architectures. A central design decision is how to fan-out updates to many users – either at write time (push to followers as soon as content is produced) or at read time (pull updates on demand when each follower’s feed is queried). This report provides a deep technical analysis of fan-out-on-write vs. fan-out-on-read strategies under extreme load. We revisit classic social feed designs (e.g. Facebook’s newsfeed vs. Twitter’s timeline) and examine how newer live platforms like TikTok Live and Twitch handle massive real-time audiences. We include real-world data – from TikTok’s billions of live chat events to record-breaking live stream viewership – to illustrate modern load patterns. Finally, we discuss emerging techniques in 2025 (hybrid push-pull models, adaptive caching, edge prefetching) and provide actionable recommendations via a decision matrix for architects of fanout-heavy systems.

Fan-Out-on-Write vs. Fan-Out-on-Read: The Basics

When a user (producer) generates new content, there are two fundamental ways to deliver it to followers (consumers):

• Fan-Out-on-Write (Push Model): The content is immediately pushed out to all followers’ feed storage or caches at publish time. In other words, the system does the work upfront – delivering or queuing the update for every subscriber as soon as it’s created. This precomputes each follower’s feed entry so reads are fast. The push model offers low read latency (feeds are prefilled) but incurs high write amplification (potentially millions of writes for one post). It also suffers from the “hot key” problem: a single popular producer (celebrity) can generate a massive burst of writes. For example, if a celebrity with 50 million followers posts, a push system might need to fan-out 50 million feed entries at once – a huge spike in workload and storage.
• Fan-Out-on-Read (Pull Model): New content is stored once (e.g. in the producer’s timeline). Followers’ feeds are left empty until they request them, at which time the system pulls updates from all the sources a user follows. In this model, writes are cheap (each post stored usually once), but read requests do more work, aggregating many producers’ posts on the fly. This avoids the celebrity hot-spot at write time (since the post is not duplicated to every follower immediately), but means higher read latency – the feed is generated on demand, which can be slow if a user follows many active accounts.

Fan-out-on-write: In the push model, a producer’s new post is immediately distributed by a fan-out service to all follower feed caches or databases. This yields fast feed reads but can overwhelm the system when a user with an enormous follower list publishes content.*

Fan-out-on-read: In the pull model, a producer’s post is written to a central timeline store. Followers’ feed requests are handled by an aggregator service that queries producers’ stores at read time. This reduces write load but makes feed retrieval slower, as it must fetch and merge many updates on each read.*

Performance Trade-offs

Table 1 summarizes key trade-offs between these approaches:

Table 1: Trade-offs between push (fan-out-on-write), pull (fan-out-on-read), and hybrid strategies.

In summary, fan-out-on-write favors read performance at the cost of expensive writes and potential overload when a single post has to be delivered to millions. Fan-out-on-read avoids massive write storms but pushes the work to each read, which can be slow or computationally heavy. Many platforms have adopted hybrid approaches to get the best of both: for example, pushing content in most cases but switching to pull-based strategies for high-fanout events or less active users. We’ll see how these strategies play out in real systems below.

Traditional Feed Architectures Under Load

Facebook News Feed (Pull-Based Aggregation)

Facebook’s News Feed provides a highly personalized list of posts from friends, pages, and groups. Notably, Facebook’s architecture has been described as primarily pull-based (fan-out-on-load). When you open Facebook, a service (often called an aggregator or “Multifeed”) gathers recent posts from all your connections and ranks them on the fly. In effect, Facebook generates your feed at read time by querying a distributed storage of recent activities (sometimes called “leaf” nodes) for each friend. This design makes sense given Facebook’s use of heavy ranking and filtering ML algorithms – it can incorporate the latest relevance scores and won’t waste effort pushing content that might never be seen. It is also resource-friendly: one experiment noted that fully materializing feeds via push would be wasteful since many users don’t log in frequently.

However, the pull model means feed generation latency is a concern. Facebook has invested in infrastructure to speed this up, such as caching and disaggregation of feed components. For example, their Multifeed system was redesigned to separate data fetching from ranking, improving efficiency. To keep reads fast, Facebook uses caching layers (e.g. maintaining an index of recent content per user on distributed leaf servers) so that fetching a user’s friends’ posts is mostly a matter of hitting caches rather than expensive database joins. The end result is that even though Facebook predominantly fans out on read, the user experience remains snappy – assuming the backend can aggregate hundreds of sources and rank them in a fraction of a second for billions of feed requests daily. This approach scales well for large networks and avoids the write amplification problem for celebrities or extremely active pages (those are naturally handled by fetching their posts on demand). On the flip side, push notifications for very important events (e.g. someone tagged you, or live video start) are handled by separate notification systems, not the feed, which is why Facebook can afford to generate the newsfeed on-load without missing critical real-time alerts.

Celebrities on Facebook: If a public figure with 10 million followers posts, Facebook’s pull model doesn’t immediately shove that post to 10 million feeds. Instead, the post is available in a backend store and will be pulled into each follower’s feed when they open the app. This avoids a huge write spike. The cost comes when potentially millions of users roughly concurrently open the app to check that post – the read fan-out still needs to happen, but it’s spread out as users come online and is easier to cache. Facebook can also defer work by not immediately serving every single follower – if some followers don’t check for hours, the work happens later for them and might even be pruned by ranking (not all followers will ultimately see the post if it’s not ranked highly for them).

Twitter Timeline (Push with Hybrid Optimization)

Twitter historically took the opposite approach: the original Twitter timeline service was largely a push-based fan-out-on-write system for delivering Tweets to followers’ timelines. Twitter’s “Home Timeline” is essentially a merged list of all tweets from accounts a user follows. Around 2011–2013, Twitter scaled this using a fan-out daemon that would take each incoming Tweet and insert a reference to it into each follower’s timeline list (stored in Redis). This made reading a timeline very fast – the tweets were already collected in one place – but at the cost of heavy write loads. By 2013, Twitter was handling ~400 million tweets per day (peak ~12k tweets/sec) and delivering ~30 billion timeline updates per day (about 300k deliveries per second). These numbers imply that on average each tweet was delivered to ~75 timelines, but in reality the distribution is very skewed: many tweets go to a handful of followers, whereas tweets from popular users go to millions.

The celebrity problem: Twitter’s engineers found that outliers with huge follower counts were a major challenge. A tweet from a celebrity (e.g. Lady Gaga’s 30+ million followers in 2013) could take minutes to fan-out to everyone in push mode. They tried to keep tweet delivery under 5 seconds, but when multiple celebrities tweeted or interacted (e.g. one celebrity replying to another), the system struggled. Queues would back up processing these massive fan-outs, leading to followers receiving tweets out of order (replies appearing before the original tweet) or with significant delay. Indeed, at p99 latency, a tweet to a large audience could take up to 5 minutes to appear in some followers’ timelines. This inconsistency was confusing to users and undesirable for a real-time platform.

Hybrid push-pull solution: Twitter evolved its architecture to mitigate this. By mid-2010s, Twitter moved to a hybrid model: continue fan-out-on-write for the majority of users (for speed), but do not fan-out fully for “high value” users (very large followings). As an engineer noted, “For people like Taylor Swift, don’t bother with fanout anymore; instead merge in her timeline at read time”. In practice, Twitter started to skip the push for accounts with followers above a certain threshold, or when the fan-out queue was too backed up. Those tweets would be fetched on-demand by followers’ timeline queries (fan-out-on-read for those cases). This hybrid approach “balances read and write paths” and saved tens of percent of computational resources, a huge win. Essentially, the system does push-based fan-out for normal users (ensuring most people get real-time updates quickly), but switches to pull for the rare cases that would overwhelm the system. Twitter also began pushing only to currently active users in some scenarios – if a follower is online when a tweet arrives, they might get it pushed, whereas offline users might just fetch later.

Caching and infrastructure: Even with hybrid fan-out, Twitter heavily relies on caching to handle read-heavy traffic. The home timeline for each user is kept in memory (Redis clusters) with up to 800 tweets cached. This protects the databases from heavy read queries. Twitter’s stack around 2013–2015 included a combination of in-memory storage, Manhattan (distributed key-value storage), FlockDB (social graph store), etc., all leveraged to make timeline reads and writes efficient. The result was that by doing more work on writes (for most users) and caching aggressively, Twitter could handle 300K QPS of timeline reads across ~150 million daily active users. Meanwhile, the writes (tweets) were only ~6K QPS – a stark 50:1 ratio of reads to writes, typical for social networks. This justified the push model: so many more reads than writes that precomputing feeds saved a ton of repeated work.

However, thanks to hybridization, Twitter’s design in 2025 is no longer a pure push; it’s adaptive. If a Justin Bieber or Cristiano Ronaldo (hundreds of millions of followers) tweets, Twitter’s backend can avoid a meltdown by not trying to immediately update every follower. Instead, many users will fetch that tweet when they load the app, or get it via a delayed fan-out. This ensures the system can absorb celebrity spikes gracefully.

Other Platforms (Instagram, Pinterest, etc.)

Other social networks have made different design choices based on their usage patterns:

• Instagram: Instagram’s feed (historically chronological, now algorithmic) has been described as a predominantly push-based model. When a user posts a photo or video, Instagram’s backend asynchronously pushes that post to each follower’s feed store (using a task queue and message broker like RabbitMQ). This made sense for Instagram because users follow a moderate number of accounts on average (so fan-out per post is manageable), and a key feature was instant delivery of new posts. Instagram’s engineering noted they use Cassandra, PostgreSQL, Redis, and Memcached to store and serve these feeds. The push approach ensures that when you open Instagram, your feed loads quickly from cached, precomputed timelines. Like Twitter, Instagram likely employs optimizations for very popular accounts – but the general strategy leans toward fan-out-on-write for timeliness. (Instagram also introduced ranked feeds later, which adds a wrinkle: they might precompute feeds periodically or use a hybrid where initial fan-out happens, then the client/apply ranking on the client or on read. But publicly, details are sparse.)
• Pinterest: Pinterest’s home feed system also chose a push model early on. New content (pins) are pushed to all followers’ feeds in a persistent store (MySQL and HBase have been cited). This ensures users see new pins from boards they follow without pulling from many sources. Given Pinterest’s focus on content discovery, they likely supplement this with recommendations (which could be fetched separately). But the core follow feed was push, favoring read speed at the cost of more writes and storage.
• LinkedIn: LinkedIn’s feed (not explicitly in our sources) is known to use a hybrid approach as well – push for some content, pull for others – and heavy pre-computation for relevance. Professional networks have fewer “celebrity” broadcasters, so they can push most updates, but LinkedIn also cares about ranking and might generate feed stories offline (e.g. via Hadoop/Spark jobs) to serve on read.
• Yahoo “Feeding Frenzy” Research: Yahoo published a paper in 2010 (“Selective Materialization: Feeding Frenzy”) that explored a hybrid feed approach. It suggests dynamically deciding per producer-consumer pair whether to push or pull, based on activity rates and cost. This research on Yahoo’s PNUTS database showed that a mix of push for frequently accessed feeds and pull for infrequent ones could minimize system load. Modern systems have effectively implemented similar ideas – classifying users or posts to decide fan-out strategy (e.g. active users get push updates, inactive ones don’t).

Key Takeaway: Traditional social feeds have converged on hybrid solutions. Facebook leans pull (due to heavy personalization and extremely large follow graphs with many infrequent connections), Twitter/Instagram lean push (for real-time feel), but all have special-cases for high fan-out events. As of 2025, any large feed system is expected to intelligently mix both strategies: push where possible for speed, pull when necessary for load shedding.

High-Traffic Live Platforms: TikTok Live & Twitch

The rise of massive live-streaming platforms brings fan-out challenges to another level. Live platforms deal with continuous, real-time event streams (video, audio, chats) and can attract millions of concurrent viewers to a single “channel” – a scenario that pushes fan-out to extremes. We examine TikTok Live and Twitch as exemplars.

TikTok Live

TikTok, known for short videos, also supports real-time live streams where popular creators can have hundreds of thousands or millions of viewers simultaneously. When a TikTok user with a huge following goes live, two major fan-out events occur:

1. Live Notification/Feed Appearance: Followers may be notified that the user is live or see the live session highlighted in their feed. TikTok doesn’t send push notifications to all followers (that could be tens of millions of push notifs), but the app does surface ongoing lives in the “Following” or “For You” sections. Internally, TikTok likely uses a selective fan-out – perhaps notifying a subset of highly engaged followers via push, and relying on in-app pull for others (when they open the app, the live is listed). This is analogous to a hybrid fan-out: the system balances between alerting users proactively and avoiding a blast to everyone. The exact mechanism isn’t public, but given TikTok’s scale, it’s safe to assume it’s carefully throttled.
2. Live Video & Chat Delivery: Once viewers join the live, the system enters a real-time broadcast mode. The live video stream itself is typically delivered via a CDN (Content Delivery Network) using a protocol like HLS or WebRTC. In essence, TikTok uses a multicast-like push for video – the streamer’s upload is replicated and sent to many viewers around the world via edge servers. This is fan-out-on-write in a streaming context (each video frame is pushed out to all viewers as it’s produced). Similarly, live chat comments from viewers are fanned-out to all other viewers in the session, usually via a publish-subscribe mechanism. For example, if 100,000 people are watching, and one person sends a chat message “Hello!”, the system will broadcast that message to the 99,999 others (often within a second or two).

Scale and numbers: TikTok’s aggregate live metrics are staggering. In 2024, TikTok Live saw “billions of viewers” total and 269 billion chat messages sent over the year. That averages to around 8.5 thousand chat events per second globally (and peaks would be much higher). A single high-profile livestream can draw millions of viewers. For instance, Ed Sheeran’s June 2021 TikTok live concert garnered over 5.5 million unique viewers (across the live and immediate replays) – the largest TikTok Live event on record. This means the platform handled millions of concurrent video streams and an immense volume of chat and reaction events for that one event. Latency is critical: viewers expect to see reactions and chats in real-time or near-real-time, and any significant lag detracts from the experience. TikTok has not published specific latency numbers, but the target is likely sub-second delivery for chats and a few seconds for video. Given the volume, TikTok’s architecture must be highly distributed: the streamer’s feed is replicated through a tree of servers and CDNs to reach viewers worldwide, and chat messages are likely sharded or sampled to manage load (e.g. in a chat with millions, not every client will receive every single chat message if the volume is too high; some rate limiting or sampling is possible to keep the experience coherent).

Edge and caching strategies: Modern live platforms like TikTok lean heavily on edge networks and adaptive strategies to handle load. TikTok routes content through edge servers globally to keep latency low and bandwidth efficient. Popular live streams are cached or replicated at edge locations near users so that millions of viewers aren’t all pulling from a central server. TikTok also reportedly caches frequently accessed engagement data (like live likes, viewer counts, etc.) at the edge to reduce database load and provide instant feedback in the UI. This is a form of edge prefetching/caching – anticipating which data (hot live streams, popular video segments, trending chats) will be needed in a region and keeping it ready locally. By 2025, such techniques are standard to ensure that even during massive spikes (e.g. a viral live event), the incremental cost to serve each additional viewer is low, since the content is already at the edge nodes.

Fan-out in TikTok Live: In summary, TikTok Live employs hierarchical fan-out. The live video and chats are fanned-out in a multi-tier network: from the broadcaster’s origin, to regional servers, to edge caches, and finally to viewers – a pipeline that can handle millions of parallel outputs. This is essentially fan-out-on-write, but implemented via streaming protocols and optimized by geography. Because live content is ephemeral, TikTok can also drop quality or skip some updates under extreme load (better to show slightly older stats than crash). The system is engineered to degrade gracefully under overload, something every fan-out-heavy system must consider.

Twitch

Twitch is a dedicated live-streaming platform, known for esports, gaming, and creative streams. It regularly handles huge concurrent audiences on single streams. Twitch’s challenges and solutions echo what we see in TikTok, with some differences in implementation.

Video distribution: Twitch uses a network of ingest servers and CDNs (often commercial CDNs plus their own) to distribute live video. A streamer sends one video stream to Twitch’s servers, which then transcode it into multiple quality levels and push it out. Viewers essentially pull video segments (or a steady stream) from edge servers. This is again a push-model fan-out at heart: one input, many outputs distributed globally. The scalability of this was proven during events like e-sports championships or special streams – for example, in July 2023, the Spanish streamer Ibai’s “La Velada del Año III” boxing event drew 3.4 million simultaneous viewers on Twitch. In 2024, Ibai broke his own record with 3.85 million concurrent viewers on a single stream, and the platform as a whole hit a peak of 6.7 million concurrent viewers during that event. These numbers show Twitch can deliver a single live video to nearly 4 million people at once, with global reach. Achieving that requires robust fan-out: the stream was likely being served from hundreds of edge servers across regions, each handling thousands of viewers.

Chat system: Twitch’s live chat is infamous – it’s an integral part of the experience (think of the rapid stream of messages and emotes in popular streams). Twitch initially used an IRC-based chat system. In the early days, a single IRC channel (chat room) for a stream could handle a few thousand users comfortably, but events like Twitch Plays Pokémon (2014), where tens of thousands of users were sending commands in chat, pushed the system to its limits. Twitch had to overhaul its chat architecture to scale horizontally. Today, Twitch’s chat uses a distributed cluster of servers. Essentially, it’s a pub/sub system: each message a user sends in a channel is published to all others connected to that channel. For very large channels, Twitch employs strategies like sharding the audience across multiple chat servers and maybe limiting message rates. Even so, chat rates of several thousand messages per second in a channel are not uncommon in top streams (which is a fan-out event for each message). The per user experience might be throttled – for example, Twitch might not deliver absolutely every message to every viewer when chat is moving at lightning speed; instead it ensures a representative, fast-flowing chat that’s manageable. This is another form of adaptive fan-out: the system delivers as much as it can to everyone, but if 100,000 people suddenly spam an emote, the client might only receive a subset or aggregated count (to avoid network thrash).

Managing spikes: Twitch has implemented features like slow mode (limiting how often each user can send messages) for chats, which indirectly controls fan-out volume. They have also introduced “Groups” or clusters in chat architecture so that the load of a very large channel is partitioned. This way, the work of fanning out messages is split among multiple servers. The underlying principle is the same: break a massive fan-out into smaller ones to keep within system limits.

Latency expectations: Twitch, being primarily interactive (especially for streamers responding to chat or viewers reacting to gameplay), aims for low latency. In recent years, Twitch introduced an “ultra low latency” mode where stream delay can be 2-5 seconds from broadcaster to viewer. Chat messages usually appear in under a second to others. Achieving this at scale means the fan-out path must be highly optimized and mostly in-memory. By 2025, Twitch likely uses custom protocols over WebSockets or QUIC for chat, and a mixture of UDP multicast within datacenters or WebRTC for video to reduce overhead. (Twitch hasn’t publicly detailed all aspects, but their engineering blog and talks like “Twitch’s Chat Architecture” discuss how critical re-architecting was during the Twitch Plays Pokémon craze to handle the unexpected load.)

Real-world load patterns: Outside of record-breaking events, Twitch typically has thousands of live channels with viewer counts ranging from a handful to hundreds of thousands. This means the infrastructure constantly handles a mix of many small fan-outs and a few huge ones. The edge caching concept is heavily used: popular streams’ video segments are cached at ISP-level edge caches, sometimes even pre-fetched as soon as created. Chat infrastructure remains centralized but distributed – not something easily cached, but ephemeral enough to handle with memory and fast networks.

In summary, Twitch’s architecture demonstrates that push-based fan-out (for video and chat) can scale to millions, provided you distribute the load horizontally and use edge networks. Like TikTok, Twitch essentially builds a tree of distribution: the root receives one stream, branches replicate it, leaves (edge servers) deliver to viewers. For chat, each chat server handles a branch of the audience. The combination ensures that no single process is trying to individually send data to a million people – the work is split among many machines.

Emerging Techniques and Best Practices in 2025

As user bases and engagement grew, systems in 2025 employ new techniques to handle fan-out at scale. These techniques often combine push and pull intelligently, and leverage caching and edge computing to minimize latency and backend load:

• Hybrid Push-Pull Models: Almost all large-scale feed or messaging systems now implement a hybrid strategy rather than a strict push or pull. This can be user-based (e.g. classify each follower or each producer as push or pull) or situation-based (depending on load). For example, one hybrid approach is to mark active or important followers as push targets and inactive ones as pull targets. When an event occurs, the system pushes to the push-target users immediately, and for pull-target users it will only fetch the update when they actually request their feed. This kind of adaptive fan-out reduces wasted work (no point pushing to someone who won’t open the app until next week) while still giving real-time delivery to heavy users. Twitter’s choice to not fan-out to extremely high-fanout users is one example; another might be a live stream platform deciding that if a stream exceeds 1M viewers, perhaps stop sending individual “X joined” notifications to everyone, because the volume is too high. Instead, aggregate or let users pull that info on demand. The hybrid model is a best practice now because it allows graceful scaling: the system can dynamically shift more toward pull when experiencing heavy write load, or shift toward push when reads are the bottleneck. In essence, “merge the read and write paths” as needed.
• Adaptive Caching and Precomputation: Caching is one of the unsung heroes in fan-out architectures. Modern systems use adaptive caching at multiple levels. For feeds, this means keeping recently used feeds in memory, caching results of expensive queries, and even precomputing feed fragments. For instance, if a celebrity’s new post is likely to be viewed by millions, the system might cache that post’s content and metadata in a fast store (like an in-memory KV cache or a CDN) as soon as it’s created, so that any component that needs it can retrieve it without hitting the primary database. Another adaptive tactic is content popularity caching: if a particular live video or post suddenly goes viral, the system detects the surge and starts caching that content aggressively in regional servers. We saw an example at TikTok where “frequently watched videos [are] cached at edge locations” for instant loading. Similarly, Twitter’s use of Redis for home timelines is a cache to avoid recomputation, and Facebook’s leaf servers cache recent friend activities. In 2025, these caches might be AI-assisted – e.g. using machine learning to predict which content will spike in popularity and preemptively load it into cache (somewhat like a recommendation system feeding into caching). The effect is to smooth out load: when the spike actually hits, the data is ready in fast storage. Adaptive caching also means expiration and invalidation are tuned; e.g. a feed result might be reused for a few seconds for users who come in bursts, rather than recompute for each.
• Edge Prefetching and Edge Computing: With the expansion of CDN and edge cloud networks, moving computation closer to users is increasingly common. Edge prefetching involves fetching or pushing data to servers near the end-users before they actually request it. A practical example: when a user is actively scrolling their feed in a mobile app, the app (or edge server) might already fetch the next batch of posts in anticipation. If a celebrity just posted a video, edge servers in regions with many of that celebrity’s followers might pull that video and store it locally, expecting a surge of requests. If the surge doesn’t materialize, the edge cache can evict it later, but if it does, those requests are served locally, reducing latency and central load. Edge computing can also handle some logic: for instance, filtering or aggregating data at the edge. We saw hints of this with TikTok caching engagement counts at the edge – rather than every like on a live video requiring a trip to a central database, edge servers can tally likes and periodically sync. That way, when you tap like and your friend near the same region does too, the increment might be handled locally and immediately reflected to nearby viewers, then merged globally. By 2025, edge functions (like AWS Lambda@Edge, Cloudflare Workers) allow developers to run custom code on CDN nodes. This opens up possibilities such as doing partial feed assembly at the edge. Imagine an edge worker that knows the top 100 trending posts in its region (kept updated via a push from the core), and when a user opens the app, it merges those trending posts with the user’s personal follow list from origin. This hybrid edge approach could accelerate feed delivery, especially for widely popular content. While not all platforms disclose such implementations, the trend is to reduce round-trip time and offload central systems by leveraging the geographically distributed infrastructure.
• Quality of Service & Graceful Degradation: Modern systems also include controls to handle overload elegantly. This isn’t a single technique but a set of best practices. For example, if push queues start backing up, the system might start dropping or coalescing some fan-out messages (e.g. combine several updates into one, or skip non-critical ones) to catch up. If read load is too high, maybe serve slightly stale data from cache rather than hitting the database for every request (trading a bit of freshness for performance). Systems like Twitter have historically dealt with overload by deprioritizing less critical deliveries – e.g. timeline updates might lag, but direct mentions or messages still get through, because the latter are user-addressed. A live system under extreme chat load might temporarily increase the chat throttle (so users can only send 1 message per 30 seconds instead of 5 seconds) to reduce fan-out volume. These adaptive QoS measures ensure the service stays up during a celebrity spike, even if not all updates are delivered in real-time.
• Microservices and Dedicated Pipelines: Architecturally, splitting the fan-out work into dedicated services is a best practice. For instance, a Fanout Service (as depicted earlier) sits between the write API and the storage, buffering and distributing updates. This can be scaled independently – more worker instances can be added to handle spikes. Similarly, a dedicated Notification Service might handle push notifications (which is another form of fan-out separate from feed delivery). By decoupling components, one can apply specific optimizations: e.g. the feed fan-out service can be optimized for bulk inserts and use batch writes to databases, whereas the read path aggregator can be optimized for fast multi-get queries. This microservice approach was hinted at in Twitter’s description (fan-out implemented as microservices, separate from the Tweet ingest API). Come 2025, it’s common to also separate “real-time pipeline” from “batch pipeline.” A real-time pipeline handles immediate fan-out (for users online, or for live content), and a batch or offline pipeline may recompute or backfill feeds for users who come later or for ranking purposes. This separation ensures that time-critical updates are handled with priority, and less urgent updates go through cheaper, slower paths.
• Data Partitioning and Sharding: To support massive scale, data (like user feeds or chat channels) is partitioned across servers. Each partition handles a subset of users or a subset of content. By hashing or logically dividing the social graph, no single machine deals with all of a celebrity’s followers at once – the load can be split. For example, if a celebrity has 50 million followers, those followers might be divided across 100 shards (500k each). The celebrity’s post fan-out task can then be parallelized across those shards, each doing 500k inserts. This is another way to fan-in then fan-out: a central coordinator splits the work and many workers execute in parallel. This technique has been around, but in 2025 the tooling (like distributed queues, autoscaling worker pools) is very mature.

All these techniques aim at one goal: deliver content reliably and quickly to vast numbers of users without breaking the system. The combination of hybrid fan-out logic, smarter caching, and pushing workload to the edge has redefined best practices.

Recommendations for Building Fanout-Heavy Systems (2025)

Building a modern social feed or live notification system requires carefully balancing trade-offs. Here we present actionable recommendations and a decision matrix for architects:

1. Embrace Hybrid Fan-Out: Design your system from day one to support both push and pull fan-out. Pure push or pure pull will falter at scale. Use push (fan-out-on-write) for most scenarios to ensure low read latency and a realtime feel, but identify conditions to switch to pull. Common triggers: if fan-out target count > X (e.g. user has > 500k followers) or if the system is overloaded. For those cases, skip immediate fan-out and handle on read or via a background job. This hybrid approach future-proofs your architecture for celebrity spikes.

2. Classify Users and Content: Not all users are equal in their usage patterns. Implement logic to categorize users into tiers – e.g. “active daily” vs “logs in rarely”, or “10M followers” vs “10 followers”. You can then fan-out accordingly: Active consumers can have a precomputed feed (so they get instant updates), while infrequent users’ feeds can be computed on demand (saving work). Likewise, for producers: a user who posts 100 times a day might be treated differently (maybe more pull-based) than one who posts once a week. This classification (potentially using ML on user behavior) can significantly reduce unnecessary work.

3. Use Distributed Queues and Bulk Operations: When pushing to many receivers, don’t attempt a single giant loop in one process. Use a distributed queue system (like Kafka, AWS SQS, etc.) to distribute fan-out jobs. Break large fan-out tasks into smaller batches (by follower shards or by time slices). This provides resilience – if one batch fails, it can be retried without halting the whole fan-out. Also, take advantage of bulk writes: insert multiple feed records in one database call if possible, or use pipeline techniques, to amortize cost.

4. Cache Smartly, at Multiple Levels: Introduce caching at every stage where it makes sense. Maintain an in-memory cache for each user’s feed (so most reads hit memory, not disk). Cache popular content and metadata in a global cache to avoid repeated computation (e.g. have the text of a popular tweet or post ready so you don’t hit the database millions of times). Use CDN or edge caches for media (images, videos) and even for API responses when feasible. Implement TTLs and invalidation carefully: e.g. a feed cache might expire after a short time or when it knows a new post arrived. Also consider write-through caches for fan-out: when pushing a post to followers, write it to cache at the same time so that followers who check immediately get it from cache.

5. Leverage Edge Computing: Where possible, move the fan-out closer to users. This can be done by deploying feed services in multiple regions or using edge cloud functions. For example, if your users are global, have feed aggregator nodes in Americas, Europe, Asia, etc., each holding partial data for local users (or caching it) – so a user’s feed request can be served nearby, without always going to a central data center. Use edge prefetching for live content: if a big event is scheduled (say a celebrity plans a live Q&A at 5 PM), start warming up edges shortly before – pre-position the stream’s manifest, allocate extra capacity, and maybe even send push notification data to edge servers. This ensures minimal latency when the spike hits. Modern CDN platforms allow you to push content to edges before it’s requested; use that for anticipated fan-out events.

6. Design for Backpressure and Graceful Degradation: Integrate backpressure mechanisms so that if the system is overwhelmed, it doesn’t crash but rather slows down non-critical work. For instance, if your fan-out queue is filling up, you might stop adding new low-priority tasks to it and let it drain. If read traffic is too high on a generated feed, temporarily increase cache times (serve slightly stale data) to reduce database hits. Have circuit breakers – e.g. if the feed generation service is too slow, fall back to a simpler feed (maybe just most recent items without full ranking) rather than timing out. Users generally prefer a slightly degraded experience over no experience. Plan what features can be sacrificed under load. For example, during a huge spike, maybe skip computing “seen” indicators or don’t update view counts in real-time – those can be updated later.

7. Test with Spike Workloads: Include scenarios in your load testing where one user causes a massive fan-out (to simulate a celebrity). It’s important to see how your system behaves when one person with 1 million followers posts 10 things in a row, or when 500,000 people join the same live stream simultaneously. Ensure your monitoring can specifically track these fan-out latencies (e.g. track how long it takes to deliver to 90% of followers). Aim to keep that within an acceptable range (Twitter’s goal was under 5s, though they had p99 issues; you might aim for say p99 < 30s for truly huge fanouts, and p50 a few seconds).

8. Separate Real-Time vs Offline Processing: If your product has both real-time aspects (new posts, live chats) and offline aspects (batch recommendations, email digests), separate those pipelines. Real-time fan-out services should be optimized for low latency and high throughput, and not be clogged by batch jobs. Similarly, offline generation of feeds (like computing tomorrow’s “top posts you missed”) should not overwhelm the caching layers needed for the live feed. Isolation and dedicated resources for each path help maintain performance.

9. Choose the Right Data Stores: Use databases/streams that align with fan-out patterns. For push model, a fast write-many store is key (Nosql stores like Cassandra or DynamoDB, or even Redis if the dataset fits in memory, are good choices for writing feed entries). For pull model, a fast multi-index query engine is needed (search engines or graph databases that can fetch posts by userIDs quickly). In many cases, a combination is used: e.g. an inverted index of user->posts for pull, plus a cache of precomputed feed for push. Make sure your storage can handle the write concurrency of massive fan-out bursts – perhaps by having partition keys that distribute those writes (like userID of follower as key for feed entries, which naturally spreads out a celebrity’s writes across many partitions).

10. Monitor and Iterate: Continuously monitor how long fan-outs take and how many events are in the queue. Track cache hit ratios for feed reads (a lower hit rate might indicate too much pull happening). Use analytics to identify “hot spots” – e.g. if certain users or events regularly cause spikes, consider special-casing them (maybe those should always be handled via a separate system, or you give them a dedicated server, etc.). In 2025, observability tools are sophisticated: distributed tracing can even show how a post propagated to different users and where the delays were. Use that data to fine-tune your thresholds for hybrid switching and to validate if edge caching is effective.

Finally, here is a decision matrix to help choose a strategy for different scenarios (Table 2):

Table 2: Fan-out strategy decision matrix for various scenarios and requirements.

By following the above guidelines and using the decision matrix, developers can architect systems that handle both everyday loads and sudden “flash mob” traffic from celebrity activity. The overarching theme is adaptability: a modern system should be able to adjust its fan-out behavior based on current load and the importance of the update. Pushing data proactively when it’s cheap and pulling data when pushes would be too expensive is a winning strategy that we see proven at the largest scales (from Facebook’s feed queries to Twitter’s hybrid timelines to TikTok’s edge-cached live videos).

In conclusion, fan-out-on-write vs fan-out-on-read is not an either/or choice in 2025 – the best systems combine both. They push when they can, pull when they must, and cache everywhere in between. By re-evaluating these trade-offs with real-world evidence and adopting new techniques like hybrid models, adaptive caching, and edge prefetching, engineers can ensure their platforms deliver content reliably under even the most extreme “celebrity spike” traffic.