Publish-Subscribe
Pub/sub fans one event out into independent deliveries.
- PublisherPublishes a business fact without a receiver list.
- SubscriptionCreates its own delivery and filter rule.
- CompatibilityAllows schema changes for independently deployed consumers.
Context
Why this is important
Decoupling succeeds only when each subscriber owns lag, failures, and compatibility.
The distributed subscribers are hypothetical; the current shop has seven modules in one process.
Compare messaging forms
In the current shop, seven modules run together. Hypothetically, Order publishes OrderPaid after confirmed payment. Shipping, Customer Notification, and Analytics each receive a delivery through separate subscriptions and retain their own position and failures. The team takes Analytics offline, publishes more events, and proves that Shipping progresses, Analytics catches up, and duplicate delivery causes no duplicate business effect.
This is how you read the picture
- Publisher Event rather than command
- Subscription Lag per receiver group
- Compatibility Prefer additive evolution
| Comparison | Form | Distribution | History |
|---|---|---|---|
| Queue | One job to one consumer | Competing workers | Until ack or expiry |
| Pub/sub | One delivery per subscription | Independent receiver groups | Per broker contract |
| Event Stream | Reader position per group | Replay possible | Defined retention |
Benefits & limitations
Helps if:
- Several independent reactions follow the same event.
- Publishers should accept new receivers without changes.
- Delayed processing is acceptable.
Boundaries
- New subscribers do not see earlier events without retained history.
- Global ordering across subscribers is usually not guaranteed.
- An event does not replace an atomic transaction across publisher and receivers.
In practice
- Publish OrderPaid and track receipt status separately for shipping, analytics, and customer communications. Check that no subscriber takes over another’s work.
- Stop only the analytics subscriber and watch its backlog. Confirm shipping continues and analytics later catches up from its own position.
- Compare Pub/Sub with queue distribution when every subscriber must receive the message. Assess recipient coupling, retention, and replay.
Read the detailed explanation
The publisher describes an event that happened and addresses no specific receiver. The broker evaluates subscriptions and filters and creates an independent delivery for every matching consumer group.
A slow subscriber must not block others but creates its own backlog. Schema changes must remain compatible with independently deployed receivers; redelivery requires idempotency per subscription.
Queue distributes one work item to one consumer. Event Stream retains a replayable sequence with position and retention.
Check your understanding
Test yourself in three stages
ReadingCheck in the picture
How many deliveries does a matching event create?
View the solution with justification
One per matching subscription or consumer group.
ApplyingTransferred to a new situation
Why does the Analytics outage not block Shipping?
View the solution with justification
They own separate subscriptions and backlogs.
EvaluateWeighing an alternative
When is an event stream preferable?
View the solution with justification
When later readers must replay historical events from their own position.
Explore further
These building blocks continue the thoughts of this page.
References
- Enterprise Integration Patterns · Publish-Subscribe Channel (opens in new tab)Primary documentation relevant to Publish-Subscribe.
- Amazon SNS · Developer Guide (opens in new tab)Primary documentation relevant to Publish-Subscribe.
- Azure Service Bus · Overview (opens in new tab)Primary documentation relevant to Publish-Subscribe.