Fan-out on write vs fan-out on read in HLD - Scaling Approaches Compared

Scalability Analysis - Fan-out on write vs fan-out on read

Growth Table: Fan-out on Write vs Fan-out on Read

Users	Fan-out on Write	Fan-out on Read
100 users	Writes fan-out to followers easily; low latency on reads; storage overhead minimal	Reads fan-out to fetch from multiple sources; read latency low; write simple
10,000 users	Write load increases as each write fans out to many followers; storage grows; read very fast	Write simple; read latency increases as many reads fan-out; higher DB load on reads
1,000,000 users	Write bottleneck due to many fan-out writes; storage and write throughput stressed; reads very fast	Write very simple; read latency high; DB read bottleneck; caching needed; complex read aggregation
100,000,000 users	Write system overwhelmed; huge storage; complex write partitioning; reads fast but costly	Write simple; read system needs massive scaling; caching, sharding, and CDN critical; high latency risk

First Bottleneck

For fan-out on write, the first bottleneck is the write throughput and storage. Writing to many followers simultaneously stresses the database and storage systems.

For fan-out on read, the first bottleneck is the read throughput and latency. Reading from many sources on demand causes high load and slower responses.

Scaling Solutions

• Fan-out on Write: Use horizontal scaling with write partitioning (sharding) to distribute writes; employ asynchronous background jobs for fan-out; use efficient storage like append-only logs; compress data; use write-optimized databases.
• Fan-out on Read: Use caching layers (Redis, Memcached) to reduce DB reads; implement read replicas; use CDNs for static content; batch and parallelize reads; pre-aggregate data where possible.
• Both approaches benefit from load balancing and monitoring to detect hotspots early.

Back-of-Envelope Cost Analysis

Assuming 1 million users, each with 100 followers, and 1 write per user per day:

• Fan-out on Write: 1M writes x 100 followers = 100M write operations/day ≈ 1157 writes/sec. This stresses write throughput and storage.
• Fan-out on Read: 1M reads x 100 followers = 100M read operations/day ≈ 1157 reads/sec. Read DB and network bandwidth stressed.
• Network bandwidth: If each operation transfers 1 KB, 1157 ops/sec x 1 KB = ~1.1 MB/s, manageable but grows with scale.
• Storage: Fan-out on write stores 100x more data; fan-out on read stores less but requires more read capacity.

Interview Tip

Start by explaining the difference between fan-out on write and fan-out on read in simple terms. Then discuss how each scales with users and data. Identify the bottleneck clearly and propose targeted solutions. Use numbers to justify your reasoning. Finally, mention trade-offs like latency, storage cost, and complexity.

Self Check Question

Your database handles 1000 QPS. Traffic grows 10x. What do you do first?

Answer: Since the DB is the bottleneck, first add read replicas and implement caching to reduce load. If writes are the bottleneck, shard the database and use asynchronous fan-out to distribute write load.

Key Result

Fan-out on write shifts load to writes and storage, causing write bottlenecks at scale; fan-out on read shifts load to reads, causing read latency and throughput bottlenecks. Choose approach based on workload and optimize accordingly.