Fan Out

Some modern systems must deliver the same message or workload to many recipients simultaneously, such as an enterprise software sending order details across departments or a chat app delivering messages to several users in a group. Fan-out is the pattern that enables this one-to-many distribution.

What Is Fan-Out?

Fan-out is an architectural pattern whereby a single source sends messages to multiple destinations simultaneously, commonly implemented in publish/subscribe (pub/sub) systems and parallel task queues. A single event can trigger many parallel actions or be delivered to many subscribers in one go.

In this pattern, one input generates multiple outputs concurrently. In a social media network or activity feed, whenever a user creates a new post, it is shared with all followers' timelines. In a chat system, a message sent to a channel is then distributed to all connected users.

It's also used more broadly in system design, powering event distribution in microservices architectures, parallel data processing in distributed computing, and broadcasting updates to Internet of Things (IoT) devices.

Because it delivers to multiple consumers in parallel, the workload can scale as the number of consumers increases (assuming the infrastructure has the capacity to support it).

How Does Fan-Out Work?

Fan-out works by distributing a single event into multiple, parallel tasks or messages and executing them concurrently. The overall step-by-step process is as follows:

1. Trigger: A single event occurs and initiates the distribution process, such as a user action, incoming message, or scheduled job.

2. Task or message duplication: The system determines the targets and prepares the message or workload for multiple recipients. For data processing jobs, the workload may be split into smaller, independent tasks.

3. Distribution: The messages or workloads are then distributed to multiple consumers in parallel, often by message brokers or application logic, depending on the architecture.

4. Parallel processing: Each consumer processes its assigned task concurrently in isolation.

5. Completion: The process ends after all parallel tasks complete independently. If one branch fails, it is often retried or handled independently while other processes continue to run.

Implementation Methods 

There are two main approaches to implementation:

• Fan-out-on-write (push model): As soon as the event occurs, the system immediately pushes or pre-distributes it to all targets. For example, when a user creates a post, the system writes it to each follower's social feed. This makes read operations very fast, but it increases write costs.

• Fan-out-on-read (pull model): The system withholds distributing the event until a consumer requests it. Using the same example, rather than writing to all feeds upfront, the system stores the post in a single source feed. Whenever a user opens their timeline, it pulls relevant events on demand. This approach spreads out tasks over time and reduces write overhead.

You can use a hybrid of the push and pull models. The choice of which model to use depends on the messages or workloads. Heavy fan-out-on-write time can handle bursts and simplify reads, whereas on-read is more suitable for infrequently accessed data.

A hybrid setup works well for:

• Social Media: On-write for popular users while handling less-connected users on demand.

• E-commerce: On-write for payment processing, fraud systems, and inventory updates, with on-read for recommendations or analytics dashboards.

• Manufacturing: An IoT temperature sensor sends readings immediately to safety devices, but a monitoring dashboard needs to request them.

Popular Implementations

Below are some key implementations:

• Apache Kafka: Kafka uses a pub/sub model where producers publish messages to topics. Consumers subscribe to the topics, and they can access messages from the same stream independently on their own time.

• Redis: Redis supports a lightweight pub/sub model. Whenever a client publishes on a channel, all subscribing clients receive the message concurrently, providing a one-to-many delivery. Redis streams and lists also fan out messages to multiple processing workers.

• MQTT and IoT Brokers: MQTT enables reliable, asynchronous messaging between clients, like the temperature sensor mentioned above. Multiple monitoring or alerting services can subscribe and receive each reading in parallel.

• Amazon Simple Notification Service (SNS): An AWS-native pub/sub service where publishing a message to a topic sends it to all subscribed endpoints, like Lambda functions. This approach decouples producers from consumers, allowing for easy processing.

What Are the Benefits of Fan-Out?

It can provide your team with the following advantages:

Parallel Processing and Broad Distribution

This system distributes events across many consumers for concurrent execution and wide distribution.

A single publish can trigger dozens of downstream tasks simultaneously, reducing latency. It also supports high throughput by spreading work across multiple processors or destinations at once.

Scalability

It supports scaling to a large audience or workloads. If you have a growing audience, it can scale consumers horizontally without touching producers. Cloud-native services like SNS can distribute millions of messages to subscribers without manual intervention.

Decoupling of Components

This architecture naturally supports loose coupling. When producers emit events, they don't need to know which consumers exist. Consumers can independently subscribe to relevant topics or feeds and process events at their own pace.

Each parallel task runs independently, meaning a failure in one path is less likely to affect others. If one consumer crashes, others still complete, improving overall system resilience. 

Efficient Resource Utilization

It maximizes available resource usage. If you run bursty workloads, it keeps CPU cores and servers busy by spreading work across many consumers.

When your customers place an order on your e-commerce app, this pattern allows multiple services (like payment, shipping, and inventory systems) to process the transaction in parallel, reducing the risk of bottlenecking that's present in monolithic architectures.

What Are the Challenges?

While it has multiple benefits, you may face some challenges, such as:

Hot Key Problem (Celebrity Spikes)

In some systems, a single event can trigger a large number of writes, causing your system to bottleneck. For example, in social apps, when a celebrity user with millions of followers creates a viral post, the system shares it to millions of users' feeds simultaneously, which can cause bottlenecks or delays.

You must carefully throttle, queue, or skip certain cases to mitigate this problem. Employing a hybrid on-write/on-read model can also help here.

Message Duplication

In some situations, subscribers receive the same message more than once due to network issues, retries, or broker failover.

Certain protocols, like MQTT, have Quality of Service guarantees that prevent message duplication, but this won't work in every scenario. Building idempotent consumers is a safer way to prevent processing issues.

Fault Tolerance and Error Handling

Each branch of this implementation can fail, retry, or lag independently, causing backpressure or duplicate processing issues. You can implement exponential backoff, dead-letter queues, timeouts, and circuit breakers to protect downstream services and isolate failures.

Ordering and Consistency

It's difficult to ensure all consumers receive events in the correct order. Messages arrive in different sequences, with some lagging temporarily. You can add timestamps or sequence numbers to messages to solve this, but this comes at the cost of increasing overhead, which is challenging at scale.

When Should You Use Fan-Out in Your Apps?

Below are some ideal use cases:

Social Feeds

Activity feeds rely on it to keep followers' timelines up to date. You can combine both push and pull models to run highly interconnected networks. On-write ensures new content is available on each feed as soon as it's posted, while on-read handles less urgent or larger feeds.

Real-Time Chat and Collaboration

Real-time chat and collaborative apps use it to broadcast to many participants.

When one user sends messages in a group chat or edits a shared document, the system delivers the update to all who are connected. You can also use WebSockets, Pub/Sub channels, or chat-specific brokers to streamline the broadcast.

IoT

Central controllers benefit from this architecture, using the one-to-many model for message and command distribution across devices. MQTT brokers and IoT hubs send control messages to subscribers, like turning off the lights or changing the temperature. You can also fan out sensor readings into multiple alerting or analytics services.

Notifications and Alerts

Whether for marketing or emergency broadcast purposes, this distribution pattern excels when you need to send notifications or alerts to multiple endpoints. One event can generate several independent messages without duplicating the trigger logic, such as sending storm warnings over SMS, email, push notification, or a weather app dashboard.

Frequently Asked Questions