The Fan-out Pattern: One Message, Many Receivers
The fan-out pattern uses a single message to trigger multiple parallel actions, like a press conference where one announcement reaches many reporters. Use it for events like a new user signup that triggers emails, analytics, and fraud checks.
WHY IT EXISTS: Systems often need to perform multiple, independent tasks in response to a single event. Tightly coupling the event producer to every consumer creates a brittle system where a single slow or failing consumer can block the entire process. The fan-out pattern was created to decouple these components for better resilience and scalability.
THE MENTAL MODEL: Think of a central message hub or "topic" as a press conference podium. A producer makes a single announcement (publishes a message) to this topic. The topic then broadcasts this message to every "subscriber" who has registered interest. These subscribers can be different services, queues, or functions, each processing the message independently and in parallel. The producer doesn't know or care who is listening.
HOW IT WORKS: A producer service sends a message to a single endpoint, a topic. This topic maintains a list of subscribers. Upon receiving the message, the topic service immediately copies and pushes it to all its subscribers. Common subscribers include message queues (like SQS), serverless functions (like Lambda), or HTTP endpoints. Each subscriber receives an identical copy of the message and processes it on its own timeline, without affecting the others.
WHEN TO USE IT: Use fan-out when a single business event needs to trigger multiple, distinct workflows. For example, after an e-commerce purchase, you might need to update inventory, send a confirmation email, notify the shipping department, and update a data warehouse. Instead of the order service calling four other services, it publishes one "OrderPlaced" event to a topic.
WHEN NOT TO USE IT: Avoid this pattern for coordinated, sequential workflows where the output of one step is the input for the next; a pipeline or saga pattern is better. Also, if you only ever have one consumer for a message, a simple point-to-point queue is more direct and less complex.
ONE CANONICAL EXAMPLE: Amazon Simple Notification Service (SNS) is a classic implementation. You create an SNS topic, like user-signups. A user service publishes a message to this topic whenever a new user registers. This topic can have multiple subscribers: an SQS queue that batches signups for analytics, a Lambda function that sends a welcome email, and another service that runs a fraud check. The user service is completely decoupled from these downstream actions.
Read the original → docs.aws.amazon.com
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.