Fan-out on write vs fan-out on read in HLD - Architecture Trade-offs

Problem Statement

When a system needs to deliver updates to many users, doing all the work at once can cause delays or overload. If the system tries to send updates to every user immediately when data changes, it can slow down writes and increase failure risk. Conversely, if it waits until users request data, the read requests can become very slow and heavy, causing poor user experience.

Solution

Fan-out on write spreads the work of sending updates to all users right when data changes, so reads are fast later. Fan-out on read delays sending updates until a user asks for them, doing the work on demand to keep writes fast. Each method balances load differently between writing and reading to keep the system responsive.

Architecture

Data Source

(Write)

→Fan-out on

↓

Data Source

(Write)

→Fan-out on

The top diagram shows fan-out on write where updates are pushed to user feeds immediately after data changes. The bottom diagram shows fan-out on read where user feeds are generated when users request them.

Trade-offs

✓ Pros

→

Fan-out on write makes user reads very fast since data is precomputed.

→

Fan-out on write reduces read-time computation and latency.

→

Fan-out on read keeps writes fast and simple, avoiding write bottlenecks.

→

Fan-out on read saves storage by computing feeds only when needed.

✗ Cons

→

Fan-out on write can cause slow writes and overload if many users must be updated.

→

Fan-out on write requires complex mechanisms to keep feeds consistent and handle failures.

→

Fan-out on read can cause slow reads and spikes in load when many users request data simultaneously.

→

Fan-out on read may lead to repeated computation for popular data, increasing resource use.

Use fan-out on write when read latency must be minimal and write load is manageable, typically under millions of users. Use fan-out on read when write speed is critical and user base is very large or highly dynamic.

Avoid fan-out on write if your system has extremely high write rates or millions of users causing write bottlenecks. Avoid fan-out on read if your application requires instant read responses or has predictable read patterns that benefit from precomputation.

Real World Examples

Twitter

Uses fan-out on write to push tweets to followers' timelines immediately, ensuring fast read experience.

Facebook

Uses a hybrid approach but relies heavily on fan-out on read for large user bases to compute news feeds on demand.

Instagram

Uses fan-out on write to deliver posts to followers quickly, optimizing for fast feed loading.

Alternatives

Hybrid Fan-out

Combines fan-out on write for active users and fan-out on read for less active users.

Use when: When user activity varies widely and you want to balance write and read load dynamically.

Pull-based Feed

Users fetch updates directly from source without precomputed feeds.

Use when: When user base is small or real-time data is critical without caching.

Summary

Fan-out on write pushes updates to all users immediately, making reads fast but writes heavier.

Fan-out on read delays update delivery until users request data, keeping writes light but reads heavier.

Choosing between them depends on system scale, read/write load, and latency requirements.