Fan-Out and Fan-In

When building scalable and reliable systems, two architectural patterns appear repeatedly: Fan-outand Fan-in.

These are not just distributed systems buzzwords – they are foundational design patterns used to scale workloads, process tasks efficiently, and coordinate results across services.

What is Fan-out?

Fan-out is a pattern where a single task or event is divided into multiple smaller tasks that execute in parallel.

Instead of processing everything sequentially, the workload is distributed across multiple workers, services, or processes to improve performance and scalability.

Think of it like a manager delegating work across an entire team rather than handling every task alone.

How Fan-Out Works

A single incoming request triggers several downstream operations simultaneously.

This enables:

• Faster processing
• Better scalability
• Independent task execution
• Improved resource utilization

Example 1: Imagine Processing System

Imagine a platform where users upload images.

Once an image is uploaded, the system may need to:

• Generate thumbnails
• Extract metadata
• Apply filters
• Run face detection

Instead of performing these tasks one after another, the system fans out the image into multiple parallel jobs.

Each microservice handles a specialized responsibility independently.

As a result, the overall processing time is significantly reduced.

Example 2: E-commerce Order Processing

When a customer places an order, multiple operations need to happen:

• Payment validation
• Inventory update
• Shipment initiation
• Confirmation email delivery

Rather than executing these tasks sequentially, the order event fans out to multiple services at the same time.

This improves responsiveness and ensures the system can handle high traffic efficiently.

The Core Fanout Problem

Fanout fundamentally asks:

When should we distribute data?

There are two major strategies:

1. Fanout-on-write
2. Fanout-on-read

Fanout-on-write

Also called:

• push model,
• precomputation model.

When a user posts:

• immediately push content to follower feeds.

Example:

User posts tweet
↓
System writes tweet into every follower feed

So later reads becomes extremely fast.

Advantages:

1. Fast reads as feed already exists

Just fetch:

GET /feed

2. Very low latency

3. Better user experience

• Feeds load instantly
• Critical for:
  • social media,
  • real-time systems

4. Easier caching

• Precomputed feeds cache well

Problems with Fanout-on-write:

1.  Massive write amplification

• One post may create:
  • millions of database writes.

Example:

1 tweet -> 50 million feed updates

Huge infrastructure cost.

2 Celebrity Problem

Users with massive followers become hotspots.

This is called:

• hot partition problem,
• hot key problem.

3 Queue Overload

Feed generation pipelines may become overwhelmed.

Fanout-on-Read

Also called:

• pull model,
• lazy computation.

Instead of precomputing feeds:

Generate feed when user opens app

At read time:

• gather posts dynamically,
• merge results,
• rank content.

Advantages of Fanout-on-read:

1.  Cheap writes

One post = one database write.

Very scalable for posting.

2. Better for Celebrity Accounts

No massive feed propagation.

3. More flexible Ranking

Feed generated dynamically.

Useful for:

• recommendation systems,
• ML ranking,
• personalized feeds.

Problems with Fanout-on-Read

1. Expensive Reads

Generating feeds dynamically is computationally expensive.

Need:

• joins,
• aggregation,
• ranking,
• sorting.

2. High Latency

Feed generation takes time.

3 Complex Caching

Every user's feed may differ.

Harder to cache efficiently.

Hybrid Fanout Architecture

Most large systems use hybrid approaches:

For example:

Normal Users

Use fanout-on-write.

Because:

• follower counts are manageable.

Celebrities

Use fanout-on-read.

Because:

• write amplification becomes enormous.

This is exactly how many social systems scale.

What is Fan-in?

Fan-in is the opposite of fan-out.

In this pattern, multiple inputs, events, or results are collected and consolidated into a single output or workflow.

Think of it like a reporting manager gathering updates from different teams before preparing one final report for leadership.

How Fan-in Works

Different services or processes produce outputs independently, and another component aggregates them into a unified result.

Fan-in is commonly used for:

• Aggregation
• Coordination
• Workflow completion
• Analytics pipelines

Example 1: Logging service

Consider the logging service which have multiple input sources:

• Auth service
• Notification service
• Payment service

All these services eventually fan in to centralized logging service.

Fan-out vs Fan-in

Real-World Systems Use Both

Most modern distributed systems combine fan-out and fan-in patterns together.

Example: Video Streaming Platform

Consider a platform like YouTube.

Fan-out Phase:

When a user uploads a video, the system triggers multiple parallel processes:

• Audio extraction
• Thumbnail generation
• Multiple video encodings (1080p, 720p, 480p)
• Content moderation
• Metadata extraction

All of these tasks run simultaneously.

Fan-in Phase:

Once every processing task completes successfully, the results are aggregated.

The system then marks the video as:

“Ready to Watch”

This combination allows the platform to process videos efficiently while maintaining a smooth user experience.

Final Thoughts

Fan-out and Fan-in are essential patterns in modern system design.

• Use Fan-out when you need to divide work into smaller parallel tasks.
• Use Fan-in when you need to combine multiple results into a single outcome.

In practice, scalable systems often rely on both patterns working together:

The next time you design a distributed system, ask yourself:

• Do I need to split this workload into parallel tasks?
• Or do I need to consolidate multiple outputs into one result?

Most likely, the answer will involve a combination of both.

Resources:

• dev.to
• medium