Think about the [Meta Post Privacy](/learn/system-design/questions/facebook-post-privacy) question: a user publishes a single post, and that post needs to show up in the feeds of every one of their followers. For someone with 500 followers, that's straightforward. But for a celebrity with 10 million followers? That single write must somehow become readable by 10 million people in their personalized feeds — fast. This is the **fan-out problem**, and it's one of the most important scaling challenges in social media, messaging, and notification systems. The core tension is simple: do you pay the cost at write time or at read time? Each approach has clear trade-offs, and real systems like Twitter and Instagram use a clever combination of both. ## Fan-Out on Write (Push Model) The **fan-out-on-write** approach precomputes every follower's feed at the moment a post is published. When a user creates a post, a fan-out service immediately writes a reference to that post into every follower's precomputed feed. Each follower's feed becomes a simple list — reading it is an O(1) fetch. The cost is O(followers) writes per post. For a user with 1,000 followers, that's 1,000 writes — completely manageable. The massive advantage is that reads are instant: when someone opens their feed, you just fetch a pre-built list. No joins, no merging, no computation at read time. This is the default strategy for most users in most systems. It works beautifully when follower counts are moderate (hundreds to tens of thousands). The write pipeline typically flows through a message queue like Kafka: the Post Service publishes a new-post event, fan-out workers consume it, look up the author's follower list, and append the post reference to each follower's feed in a store like Redis or DynamoDB. **See it in practice:** In [Slack](/learn/system-design/questions/slack), messages posted to a channel are fanned out to all channel members' inboxes. In [Google Calendar](/learn/system-design/questions/google-calendar), a new event invitation is pushed to each attendee's calendar view. The [Pub/Sub Messaging](/learn/system-design/design-patterns/pub-sub-messaging) pattern covers the underlying event-driven architecture that powers these fan-out pipelines. ## The Celebrity Problem Fan-out on write has an Achilles' heel: **celebrities**. When someone with 10 million followers publishes a post, that single write triggers 10 million feed updates. Even with efficient workers and message queues, propagating to all followers can take minutes — and during that time, the system is under enormous write pressure. This isn't a theoretical concern. Twitter famously struggled with this exact issue when celebrities like Lady Gaga tweeted. A single tweet could generate hundreds of millions of fan-out writes across the system, creating cascading delays for all users. The math is brutal: if your fan-out workers can handle 100,000 writes per second, a 10-million-follower post takes 100 seconds — almost two minutes — just for propagation. And if that celebrity posts three times in a row, you're looking at a five-minute backlog. ## Fan-Out on Read (Pull Model) The opposite approach is **fan-out-on-read**: don't precompute feeds at all. When a user opens their feed, the system queries the posts table for every user they follow, merges the results by timestamp, and returns the combined feed in real time. Write cost drops to O(1) — you just store the post once. But the cost shifts entirely to read time: O(following) fetches per feed request. If a user follows 500 accounts, opening their feed means 500 lookups merged in real time. For most users, this is too slow. Feed loads would take seconds instead of milliseconds, and the database would be hammered with thousands of queries per feed request. But for celebrity posts specifically, this approach makes perfect sense — you avoid the massive write amplification entirely. **See it in practice:** In [ChatGPT](/learn/system-design/questions/chatgpt), conversation history is pulled on demand rather than precomputed, since each conversation has exactly one reader. In [File System](/learn/system-design/questions/file-system), directory listings are computed at read time by querying all files with a matching parent path. The [Scaling Reads](/learn/system-design/design-patterns/scaling-reads) pattern covers techniques for making these read-time queries fast through indexing, caching, and replicas. ## Hybrid Approach The practical solution — used by Twitter, Instagram, and most large-scale feed systems — combines both strategies with a **follower threshold**. The rules are simple: - **Regular users** (below the threshold, e.g., fewer than 100K followers): fan-out on write. Their posts are pushed to all follower feeds at publish time. - **Celebrities** (above the threshold): fan-out on read. Their posts are stored once and fetched at read time. When a user opens their feed, the read path merges two sources: the precomputed feed (containing posts from regular users they follow) and freshly fetched posts from the celebrities they follow. Since most users follow only a handful of celebrities, the read-time merge adds minimal latency. The threshold is typically tuned based on system capacity. Twitter reportedly uses around 100,000 followers as the cutoff, but the exact number depends on your write throughput, acceptable latency, and infrastructure. **See it in practice:** The [Meta Post Privacy](/learn/system-design/questions/facebook-post-privacy) question directly exercises this hybrid approach — you must design the fan-out pipeline that distributes posts to follower feeds while respecting privacy settings, deciding which users get push vs. pull delivery. In [Slack](/learn/system-design/questions/slack), large public channels with thousands of members use a similar hybrid: messages are pushed to active members but pulled for inactive ones. ## Feed Cache Architecture In practice, precomputed feeds are stored in **Redis sorted sets** — one per user. Each entry in the sorted set is a post ID scored by timestamp (or a ranking signal). This gives you O(log n) inserts and O(log n + k) range queries, which is perfect for paginated feed reads. The key operations: - **ZADD**: Insert a new post reference into a follower's feed with a timestamp score. - **ZREVRANGE**: Fetch the top N posts (newest first) for a feed page. - **ZREMRANGEBYRANK**: Trim the feed to keep only the latest ~1,000 posts, preventing unbounded growth. Each feed is capped at a fixed size (typically 800-2,000 entries). When a new post is added, the oldest entry is evicted. If a user scrolls far enough back to exhaust the cached feed, the system falls back to a database query for older posts. The feed cache is not the source of truth — the posts table in your primary database is. If the cache is lost (Redis restart, eviction), it can be rebuilt by querying the follower graph and recent posts. This makes the architecture resilient: cache failure means slower feeds, not broken feeds. **See it in practice:** In [Distributed Cache](/learn/system-design/questions/cache), you design a Redis-like system from scratch including sorted sets, eviction policies, and replication. In [Leaderboard](/learn/system-design/questions/leaderboard), Redis sorted sets power real-time rankings using the same ZADD/ZRANGE primitives. The [Distributed Caching](/learn/system-design/design-patterns/distributed-caching) pattern covers cache topologies, eviction strategies, and failure handling in depth. ## Cursor-Based Pagination Feeds are paginated, and the pagination strategy matters for correctness. **Offset-based pagination** (give me items 20 through 40) breaks when new posts are inserted between page fetches — items shift positions, causing duplicates or missed posts. **Cursor-based pagination** solves this by encoding the position of the last item seen. Instead of "give me page 3," the client says "give me 20 posts older than this timestamp." This is stable under concurrent inserts because it references a fixed point in the data rather than a shifting offset. The flow works like this: 1. Client requests the first page: GET /feed?limit=20 2. Server returns 20 posts plus a cursor (the timestamp of the last post): next_cursor=1709833200 3. Client requests the next page: GET /feed?limit=20&cursor=1709833200 4. Server returns posts with timestamps older than the cursor This pattern maps directly to Redis sorted set operations: ZREVRANGEBYSCORE feed:user_42 1709833200 -inf LIMIT 0 20 fetches the next page efficiently. ## The Complete Write Path Putting it all together, the fan-out write pipeline for a production feed system looks like this: 1. **User publishes a post** — the Post Service writes it to the posts table and emits a new_post event to Kafka. 2. **Fan-out workers** consume the event, check the author's follower count, and decide push vs. pull. 3. **For regular users**: workers look up the follower list, then ZADD the post reference into each follower's Redis feed. Workers process followers in batches to avoid overwhelming Redis. 4. **For celebrities**: the post is stored in a separate "celebrity posts" table. No fan-out happens. 5. **When a reader opens their feed**: the system fetches the precomputed Redis feed, queries the celebrity posts table for any celebrities the reader follows, merges and deduplicates, then returns the result with a pagination cursor. The message queue is critical here — it decouples the post creation (which must be fast) from the fan-out propagation (which can take seconds). If the fan-out workers fall behind, posts queue up in Kafka rather than slowing down the user's publish action. The [Scaling Writes](/learn/system-design/design-patterns/scaling-writes) pattern covers write buffering with queues in detail. **See it in practice:** In [Job Scheduler](/learn/system-design/questions/job-scheduler), a similar worker-pool pattern processes queued jobs with fan-out to multiple execution nodes. In [Webhook](/learn/system-design/questions/webhook), event delivery fans out to multiple subscriber endpoints through a queue-backed pipeline. The [Pushing Real-Time Updates](/learn/system-design/design-patterns/pushing-realtime-updates) pattern extends fan-out with WebSocket connections for instant feed updates without polling.