Pub/Sub Fan-out
One event, many independent subscribers acting on it in parallel.
StarterMessagingPlatform
A producer publishes once to a topic; every interested service subscribes independently and reacts on its own schedule. Adding a new subscriber never touches the producer or its peers.
When to use it
- Multiple unrelated services must react to the same event (e.g. order placed -> billing, shipping, analytics)
- You want to add new consumers without redeploying the producer
Trade-offs
- No guarantee of processing order across subscribers
- Debugging a fan-out requires tracing across every subscriber
Components used
Serverless FunctionPub/Sub TopicContainer ServiceData Warehouse
How it works
- A publisher emits an event to a topic without knowing who consumes it.
- Each subscriber has its own independent subscription and receives its own copy, processing at its own pace.
- Adding a new consumer requires no change to the publisher, which is the entire point of the indirection.
Used in the wild
- One business event triggering several unrelated reactions — an order placed causing email, analytics and inventory updates.
- Broadcasting cache invalidation to every application instance.
- Decoupling teams so a new feature can subscribe to existing events without coordination.
Good to know
- Publishers losing visibility of consumers is both the benefit and the danger: nobody knows what breaks when an event's shape changes, because nobody knows who is listening.
- A slow subscriber does not slow the publisher, but its backlog grows silently. Per-subscription lag monitoring is what catches this before retention expires and messages are lost.
Related patterns
Model Serving with A/B Testing
Route inference traffic across model versions to compare live performance.
CQRS
Separate models and stores for writes and reads.
Change Data Capture
Stream a database's row-level changes without touching app code.
Blue-Green Deployment
Run two full production environments, switch traffic between them.