Publish-Subscribe Channel

A Publish-Subscribe Channel delivers a copy of each message to every subscriber. A publisher emits an event once; the channel fans it out to all consumers that have registered interest. The publisher neither knows nor cares how many subscribers exist, which makes it the canonical pattern for event notification.

The problem it addresses is one-to-many notification. When something happens — an order is placed, a user signs up, a price changes — many parts of a system may need to react. Hardcoding those reactions into the source couples it to every consumer. Publish-subscribe inverts this: the source announces a fact and lets others subscribe independently.

How It Works

The channel maintains a set of subscriptions. When a message arrives, the broker copies it to each subscriber's delivery path. Subscribers process their own copy at their own pace; one slow subscriber does not block others. Subscriptions can be durable, so a subscriber that was offline still receives messages emitted while it was down.

Topic-based systems route by topic name; content-based systems let subscribers express predicates over message content. Modern log-based brokers like Kafka achieve pub-sub by letting each consumer group track its own offset over a shared, retained log.

Publisher --> [ topic ] --+--> Subscriber A
                          +--> Subscriber B
                          +--> Subscriber C

When to Use It

Use it for event-driven architectures, domain event distribution, cache invalidation broadcasts, and any scenario where consumers should be added or removed without changing the producer. It pairs naturally with event sourcing and CQRS read-model updates.

Avoid it when each message must be handled exactly once by exactly one worker — that is point-to-point territory.

Trade-offs

Publish-subscribe maximizes decoupling and extensibility but complicates reasoning: a single publish can trigger wide, cascading effects that are hard to trace. Delivery guarantees vary by broker and subscription durability. Without care, subscriber explosion and event versioning become governance problems. Schema contracts and a schema registry help keep producers and consumers compatible over time.

Related Patterns

The Point-to-Point Channel is its one-receiver counterpart. A Message Filter lets a subscriber discard irrelevant messages. Event Sourcing often publishes domain events over pub-sub channels.

Example

Google Cloud Pub/Sub, AWS SNS, MQTT, and Kafka topics implement this pattern. A retail platform publishes OrderPlaced to a topic; the inventory, analytics, and email services each subscribe and react independently. Adding a fraud-detection subscriber later requires no change to the order service.