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.

Practice

1. What is the main advantage of using fan-out on write in system design?

easy

A. Simpler read logic by fetching data on demand

B. Faster read operations by duplicating data during write

C. Reduced storage usage by avoiding data duplication

D. Faster write operations by delaying data duplication

Solution

1. Step 1: Understand fan-out on write behavior

   Fan-out on write duplicates data to multiple places during the write operation.

2. Step 2: Analyze impact on read speed

   This duplication allows reads to be faster because data is already pre-distributed and ready to access.

3. Final Answer:

   Faster read operations by duplicating data during write -> Option B

4. Quick Check:

   Fan-out on write = Faster reads [OK]

Hint: Fan-out on write means write duplicates data for fast reads [OK]

Common Mistakes:

• Confusing fan-out on write with fan-out on read
• Thinking fan-out on write reduces storage
• Assuming writes are faster with fan-out on write

2. Which of the following best describes fan-out on read?

easy

A. Data is compressed during write to save storage

B. Data is duplicated during write to speed up reads

C. Data is cached permanently to reduce read latency

D. Data is fetched and combined during read to keep writes fast

Solution

1. Step 1: Define fan-out on read

   Fan-out on read means data is not duplicated during write but fetched from multiple sources during read.

2. Step 2: Understand write speed impact

   This keeps writes fast because no extra duplication work is done during write time.

3. Final Answer:

   Data is fetched and combined during read to keep writes fast -> Option D

4. Quick Check:

   Fan-out on read = Fast writes, complex reads [OK]

Hint: Fan-out on read delays data gathering until read time [OK]

Common Mistakes:

• Mixing fan-out on read with fan-out on write
• Assuming fan-out on read duplicates data during write
• Confusing caching with fan-out on read

3. Consider a system using fan-out on write. If a user updates their profile, what happens during the write operation?

medium

A. The update is duplicated to multiple storage locations immediately

B. The update is written once and read fetches combine data later

C. The update is cached temporarily and written later asynchronously

D. The update is compressed and stored in a single location

Solution

1. Step 1: Recall fan-out on write behavior

   Fan-out on write duplicates data during the write operation to multiple places.

2. Step 2: Apply to user profile update

   When a user updates their profile, the system writes the update to all relevant storage locations immediately.

3. Final Answer:

   The update is duplicated to multiple storage locations immediately -> Option A

4. Quick Check:

   Fan-out on write = Immediate duplication on write [OK]

Hint: Fan-out on write duplicates data immediately on update [OK]

Common Mistakes:

• Thinking update is written once and combined later
• Confusing caching with fan-out on write
• Assuming asynchronous write in fan-out on write

4. A system using fan-out on read is experiencing slow response times. What is a likely cause?

medium

A. Writes are slow due to data duplication

B. Storage is overloaded due to duplicated data

C. Reads are slow because data is fetched from multiple sources on demand

D. Data is compressed causing decompression delays

Solution

1. Step 1: Understand fan-out on read read behavior

   Fan-out on read fetches data from multiple sources during read, which can add latency.

2. Step 2: Analyze slow response cause

   Because reads combine data on demand, slow response times are likely due to this complex read process.

3. Final Answer:

   Reads are slow because data is fetched from multiple sources on demand -> Option C

4. Quick Check:

   Fan-out on read = Slow reads if sources are many [OK]

Hint: Fan-out on read can cause slow reads due to multiple fetches [OK]

Common Mistakes:

• Blaming slow writes in fan-out on read
• Assuming storage overload in fan-out on read
• Confusing compression delays with fan-out issues

5. You are designing a social media feed system. Which approach is better if you want instant feed updates but can tolerate higher storage costs?

hard

A. Fan-out on write to duplicate feed data for fast reads

B. Fan-out on read to keep writes fast and storage low

C. Use caching only without fan-out

D. Compress data on write to save storage

Solution

1. Step 1: Identify system needs

   Instant feed updates require fast reads with up-to-date data.

2. Step 2: Match approach to needs

   Fan-out on write duplicates feed data during write, enabling fast reads and instant updates but uses more storage.

3. Step 3: Evaluate other options

   Fan-out on read delays data gathering to read time, causing slower reads. Caching alone may not guarantee instant updates. Compression saves storage but slows access.

4. Final Answer:

   Fan-out on write to duplicate feed data for fast reads -> Option A

5. Quick Check:

   Instant updates + higher storage = Fan-out on write [OK]

Hint: Instant reads with more storage? Choose fan-out on write [OK]

Common Mistakes:

• Choosing fan-out on read for instant updates
• Ignoring storage cost impact
• Assuming caching replaces fan-out needs