I was recently having a discussion around a system being built using Microsoft Azure. Some concepts being discussed for this system where CQRS, Event Sourcing and Message Queue.
The diagram below is fairly typical when discussing CQRS and Event Sourcing.
One of the first things that stood out to me was the use of the Message Queue and Azure Service Bus.
For this blog post, I want to focus on the Service bus, which is used for publish-subscribe pattern. The domain will emit events that are stored to the event stream and then will be published to the Service Bus. Subscribers, such as Projections or other Bounded Contexts will process these events.
Forgotten Option
There is nothing wrong with using a service bus to publish domain events.
However, one option which is seemingly always forgotten to developers that are new to CQRS and Event Sourcing:
Your event stream can be used as a message queue
Other bounded contexts or projections can query/poll your event storage to retrieve new events that have been persisted.
At regular intervals, the event consumer could poll your event storage requesting any number of new events based on the last event it processed.
The consumer would be required to keep track of the last event it processed in order. This provides some benefits as it may not be a process that is required to be continuously running.
You may be thinking: Polling? Really?
If you rolled your own event storage, I could understand how this might be problematic and would likely be easier to use a service bus. Or you may want your event consumers to process the event as soon as possible. Your implementation of how to handle this is dependant on how you are currently storing your events.
But the point still remains: Your event stream is a message queue.
As always, context is king. Requirements and many other factors will play into how you want to handle messaging.
It is another option that may fit a scenario that you run into.
Event Store
If you are just thinking about getting into Event Sourcing, I would highly recommend looking at Event Store by Greg Young as your event storage.
Event Store supports multiple types of Subscriptions including Persistent Subscriptions for the Competing Consumers messaging pattern.
Pingback: The Morning Brew - Chris Alcock » The Morning Brew #1883
How do you think Event Store compares to Azure Service Bus? What are you specific reasons for choosing it over Azure Service Bus?
Although Event Store has various forms of subscriptions, I wouldn’t really compare it to Azure Service Bus. Event Store is a database for storing immutable object/events for an event sourced system. It’s just an added feature that enables you to use persistent subscriptions to get a similar effect for processing events.