Publish an event describing a business fact to a durable topic or equivalent channel.
Enterprise Messaging · Messaging Channels
Publish-Subscribe Channel
Publish once to a channel that fans the event out to every interested subscription. Producers remain unaware of how many consumers exist.
How can the sender broadcast an event to all interested receivers?Adapted from Enterprise Integration Patterns under CC BY 3.0. The visualization and explanatory content on this page are original GateSift material.
Original GateSift visualization
How Publish-Subscribe Channel works
One published event creates independent delivery opportunities so subscribers can process the same fact without the publisher knowing who they are.
Business event
Publish once
Subscriber A
Subscriber B
Subscriber C
Let each subscription apply its own filter, retry and delivery lifecycle independently.
Monitor subscriber backlog and schema compatibility separately so one slow consumer does not redefine the whole event flow.
Curated GateSift guidance
When this pattern is a good fit — and when it is not
Use publish-subscribe when one event should be independently consumed by multiple subscribers without the publisher knowing who those subscribers are.
- Multiple consumers need the same business event independently.
- Subscribers should be added or removed without changing the publisher.
- Each subscriber needs its own delivery, retry and failure lifecycle.
- Exactly one worker should process each message; use a competing-consumer queue instead.
- Consumers require a synchronous response before the publisher can continue.
- The published message is really a command intended for one owner rather than an event describing a fact.
Subscriber lagHigh impact
A slow subscriber can accumulate backlog even while every other subscriber remains healthy.
Schema evolutionReview
New event versions can break consumers that were not designed for tolerant reading.
Duplicate side effectsHigh impact
At-least-once delivery requires subscriber-side idempotency for business writes.
- Azure Service Bus topics with separate subscriptions provide durable independent delivery and filtering.
- Event Grid is a better fit for lightweight event notification where durable broker semantics are not required in the same way.
- Keep subscriber retry and dead-letter policies independent so one consumer does not dictate recovery for all others.
What this pattern helps you decide
Publish once to a channel that fans the event out to every interested subscription. Producers remain unaware of how many consumers exist.
Is this message an event that multiple consumers may legitimately own independently?
Can every subscriber tolerate duplicate delivery and temporary backlog?
How will schema changes be introduced without coordinated deployment of all subscribers?
Where you may see it
- Service Bus topics and subscriptions
- Event Grid topics
- Event Hubs consumer groups
How the analyzers can surface it
- Topic and subscription destinations
- Fan-out routing
Pattern detection is contextual. GateSift should present these as architectural signals, not claim a pattern is implemented solely because one policy statement or adapter exists.
GateSift support
Where GateSift can surface this pattern
Detection means the source contains direct structural evidence. Signal means the analyzer sees compatible structure but still needs architectural context.
Source, licence and attribution
The pattern name and selected problem statement are adapted from Enterprise Integration Patterns by Gregor Hohpe and Bobby Woolf under CC BY 3.0. GateSift summaries, Azure mappings, analyzer guidance and diagrams are original. No endorsement by the original authors is implied.