Publisher Subscriber and Event Streaming patterns

I want to talk about two typical models for working with events in an event driven architecture. These are the Publisher Subscriber (pub/sub) and Event Streaming pattern. Both have the same purpose: to communicate between different software artifacts using messages so they have similarities but also has its own characteristics.

Before getting down to business, since I mentioned event driven architecture before, I want to clarify that these patterns are prepared to transmit messages, not only events. An event is just a message that notifies that something has happened.

Publisher Subscriber pattern

The Pub/Sub pattern is like subscribing to a newspaper and then at some time in the future, the next newspaper edition is delivered to you in your house, by a young in a bicycle.

In this pattern, there are a publisher and a subscriber. The subscriber can request to “subscribe” to specific messages types, like you with the newspaper subscription. In the other hand, the publisher has the responsibility to publish new events.

Those messages need to be delivered to the subscribers, usually, this is achieved using a message broker. The message broker is an infrastructure piece that knows for every message to which subscribers must be sent, also the message broker knows what messages have been delivered to the subscribers and what messages are pending. It is like the delivery person that gives you each newspaper edition in your house.

When using this pattern if there is not any subscriber when the message is published, then that message can not be delivered to anyone, so the message is lost.

Event streaming pattern

In the Event Streaming pattern, there is also senders (publisher) and receivers (consumers), the difference is that the published events are saved in a stream store, instead of delivering it directly to the subscribers. It is important that the events are stored in order, in a fixed position. Then are the consumers who go to the stream store and check if there are new messages to process.

It is like when you go to the library and start looking for a marvel comic collection, where the library is the stream store, and you are the consumer. In the library, you can start reading the comic edition that you want, decide in which order read the comic collection, in which edition start and stop, and also if you like a comic so much you can read it many times.

The main difference is that in the streaming pattern it is every consumer who knows what messages has already processed and what messages are pending. It is consumers responsibility for advancing in the stream position to process new events. Meanwhile in the pub/sub model that responsibility belongs to an infrastructure piece, the message broker. Since are the consumers who ask for a message instead of receiving every message, it allows the consumers to decide what messages read and in which order. This also allows the consumers to read the same massage many times, so there is an easy way to implement a retry policy.

The event streaming pattern involves persistence, this allows any consumer to join and start reading the events from a stream at any time. This it is not possible in a pub/sub model, since if there is not any subscriber when a message has published that message can not be delivered.

It’s your decision

Those differences make that use one pattern or another can change the way you think in the problem. There is no a winner or a better way, as all other software architecture patterns they are tools, and both have its own advantages and disadvantages, it is up to you what pattern use in every context.