iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Fan-out on write distributes a post to followers when it is published, making later feed reads simpler at the cost of more publishing work. Fan-out on read stores a post once and gathers followed accounts’ posts when a reader opens the feed, reducing distribution work but increasing work on the read path. When audiences vary widely in size, a hybrid can push posts from ordinary accounts and pull posts from very large accounts.
What fan-out means in a feed
Fan-out is the step that makes a published post available in other people’s feeds. The central design choice is when to do that work: at publication time, or when each reader requests a feed. It is separate from ranking and recommendations, which decide what to show or in what order after candidate posts have been gathered.
Both strategies can return a dynamic feed. They differ in where they spend compute, storage, and latency budget, and the best choice depends on how publishing and reading behave in the product being built.
How fan-out on write works
With fan-out on write, the system first stores the post as its source record. It then distributes the post’s identifier to the timelines or inboxes of its followers, commonly through asynchronous workers. A reader can retrieve a prepared list rather than query every followed account for recent posts. Historical Twitter engineering presentation material depicts a write API feeding a fan-out stage and timeline cache, including Redis in the cache architecture; it documents a design pattern at the time, not necessarily the platform’s present-day implementation. See the Twitter timeline scalability presentation.
#1 Best Overall
- Read path: Usually simpler because much of the candidate timeline has already been assembled.
- Publish path: Work grows with the author’s audience because the post must be distributed to recipients.
- Freshness: If distribution is asynchronous, followers may receive the post at slightly different times; the system must decide how much lag is acceptable.
- Wasted work: Distribution to inactive followers can consume resources even when they do not open the feed.
- Operational pressure: A post from a very large account can trigger a burst of downstream work and create a queue backlog if workers cannot keep up.
The O(n) write and O(1) read labels shown in historical Twitter presentation material communicate the direction of the trade-off, not a latency guarantee or benchmark. Actual read work still depends on implementation, such as pagination, cache behavior, and any later filtering or ranking. The QCon London slides likewise should be read as historical engineering material, not evidence of current internals.
How fan-out on read works
With fan-out on read, a post is stored once on its author’s timeline. When a reader requests a feed, the system retrieves recent posts from the accounts that reader follows and merges them into a response. This avoids writing each new post separately into every follower’s feed, but moves aggregation into the latency-sensitive request path.
Rank #2
- Read path: The system may need to fetch and merge posts from many followed accounts. Followee count, data partitioning, caching, and pagination affect the work.
- Publish path: Publishing is comparatively simple because it does not trigger per-follower distribution.
- Freshness: New posts can be considered when the reader requests a feed, although caching and other implementation choices still affect what the reader sees.
- Workload fit: Pulling posts only when a feed is requested can avoid spending distribution work on followers who remain inactive.
Fan-out on read is not automatically faster or cheaper overall. It shifts costs rather than removing them: a long follow list or a demanding read-latency budget can make aggregation costly.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →How the approaches compare
| Dimension | Fan-out on write | Fan-out on read |
|---|---|---|
| Where feed assembly happens | Primarily when an author publishes. | When a reader requests a feed. |
| Work per post | Grows with the author’s audience because the post is distributed to followers. | Does not include per-follower distribution for each post. |
| Work per feed request | Often lower because candidate items are already collected. | Includes retrieving and merging recent items from followed authors. |
| Pressure point | Large author audiences, distribution bursts, and worker backlog. | Readers with many followees and the read-latency budget. |
| Inactive recipients | May receive distribution work despite not opening the feed. | Need not trigger feed assembly until they request a feed. |
| Storage and caching | Prepared recipient timelines require storage and cache capacity; exact footprint depends on implementation. | Avoids per-follower copies of each post, but still needs author timelines and may use caches; exact footprint depends on implementation. |
| Complexity to account for | Asynchronous delivery, backlog handling, and keeping recipient timelines consistent with deletes or follow changes. | Multi-source retrieval, merging, pagination, and keeping results within read-latency limits. |
These are architectural tendencies, not universal performance figures. A production system’s actual costs depend on its traffic, data layout, caches, queue capacity, and consistency requirements.
Why audience skew often favors a hybrid
A pure strategy can become expensive at either extreme. Pushing every post to every follower can make a very large author’s publication unusually costly. Pulling from every followed account at read time can make requests expensive for readers with long follow lists. Real audiences are often uneven: many accounts have modest followings while a small number have very large ones.
A hybrid precomputes timelines for ordinary authors and retrieves posts from unusually high-follower authors when assembling a reader’s feed. That bounds per-post fan-out for the largest accounts while avoiding a full read-time scan across all followed authors. It is a system-design pattern, not a claim about the current internals of any particular social platform. A useful conceptual explanation is available in this system-design overview.
Choose the cutoff from measurements
There is no established universal follower-count threshold for switching an author from push to pull. Derive a cutoff from the workload and operational limits, and revisit it as the product changes. Consider:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- How often accounts publish and how follower counts are distributed.
- How frequently readers request feeds and how many accounts they follow.
- The read-latency budget and the acceptable delay for asynchronous distribution.
- Fan-out worker capacity, queue depth, and how the system behaves during bursts or backlog recovery.
- The storage and cache cost of prepared timelines, balanced against the cost of read-time retrieval and merging.
- How much work should be spent on followers who may not return to the product.
Which strategy should you choose?
Favor more fan-out on write when
- Feed reads dominate publishing and need a predictable, comparatively light retrieval path.
- Author audiences are bounded enough that distributing posts is operationally manageable.
- The system can absorb asynchronous fan-out work and the product can tolerate its delivery behavior.
Favor more fan-out on read when
- Some authors have very large audiences, making per-follower distribution costly.
- Many potential recipients are inactive, so precomputing their timelines could be wasted work.
- Feed requests can tolerate retrieval and merging across followed accounts.
Favor a hybrid when
- Audience sizes are skewed enough that pushing for every author creates costly extremes.
- Pulling from every followed author would also strain the feed-read path.
- The team can operate both precomputed timelines and read-time sources, with clear rules for merging and handling updates.
How to evaluate the trade-off in your own system
Compare the actual hot paths rather than treating asymptotic labels as a service-level objective. Measure representative publishing and feed-read workloads, including accounts and readers at the high end of their audience and follow counts.
Quick Recap
- Characterize the workload: Measure the distribution of author follower counts, reader followee counts, post rates, and feed-read rates. Averages alone can conceal the accounts and readers that drive peak work.
- Set product constraints: Define acceptable feed latency and freshness, including how much lag asynchronous distribution can introduce.
- Load-test the paths: Test publish-time distribution, feed retrieval and merging, and the combination used by any hybrid. Include burst traffic and recovery from a worker backlog.
- Track resource costs: Monitor queue depth and processing delay, read latency, cache behavior, and storage growth. Check whether work is being spent on recipients who do not read their feeds.
- Reassess the split: Adjust which authors are pushed or pulled as measured costs and product requirements change; do not treat a cutoff as permanent.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
