Pub/Sub channels allow you to publish messages to many consumers that are interested in that message. Producer publishes and consumers subscribe.

Publish to many consumers

This pattern allows your producer to publish messages to many downstream consumers. Consumers get their own copy of the message to process.

Listening to your events

As consumers are independent from each other (own copy of the message), you can create new subscribers onto the channel and use this for debugging. An example of this would be to create a new subscriber to an event, store the information somewhere or log it out, this way you can see all events going through the producer’s channel.

Flexible

Consumers come and go, high chance your producer does not care. This gives teams the flexibility to add consumers as business requirements change or even remove them.

Push model

With pub/sub messages/events are often pushed to downstream consumers (rather than consumers having to listen and pull events of a queue/channel).

Durable Subscriptions

At times you might have subscribers that are still interested but “inactive” (no longer receiving messages), and gets the messages back when they reconnect, this is known as the durable subscriber, if you are interested it’s worth checking out that pattern.

Extra resources

• Publish-Subscribe Channel - Publish Subscribe channel from Enterprise Integration Patterns, worth a read to dive deeper.
• Durable Subscriber - Interesting pattern when subscribers are “inactive” and want to process messages they missed from a pub/sub point of view. Worth reading and understanding.
• Conway’s Law and EDA - When creating pub/sub patterns you will have many producers and consumers, understand how Conway’s law can effect all this with this visual.
• Message translator pattern - Before consuming events in your subscribers/consumers do you want to transform your data? Might be worthwhile? Dive deeper with this visual.
• Claim check pattern - When sending events, sometimes they can be too big for your broker, or you want to keep them small. Store the information with a key and let consumers get it back with the Claim check pattern.
• Content enricher pattern - Before consumers get your events can you implement some middleware to enrich them?
• Event Types - You will be sending messages/events throughout your application, know the difference between the types of events you are sending, your contract will impact your architecture choices.
• Message Brokers vs Event Brokers - Message Queues, Event Brokers what does it mean? Where does pub/sub fit into the picture of EDA. Visual to help you.