Messaging and event sourcing

By kellabyte  //  Messaging  //  5 Comments

In the event sourcing communities sometimes I hear anti-messaging statements that messaging increases complexity and messaging increases coupling so you should avoid it. I find this strange because when I look at a lot of these event sourcing implementations I can identify several messaging patterns. They are already doing messaging.

An event store is a queue and your aggregates and projections are subscribers of streams. Message queues sometimes call this a topic but there are many varying names for the same thing.

It’s important to remember not to get so hung up on the names of things and to identify the patterns.

Some event store middleware is messaging middleware

Both store messages in-order. Both allow subscribing to a topic (event stores call this a stream id).

What is the difference between Greg Young’s event store that is fronted by a HTTP AtomPub API and Azure Service Bus fronted by a HTTP AtomPub API?

Some event stores are even adding various messaging protocol support.

[tweet https://twitter.com/GetEventStore/status/379987176412684288]

Certainly both have many more features that differentiate from each other and these are only 2 implementations of many but there are common underlining patterns between them.


My opinion is many event sourced systems I’m seeing are message-oriented publish/subscribe systems so these anti-messaging statements conflict.

  • Greg Young

    I’m not sure how anyone would ever get the opinion that event sourcing is not messaging? Projections are also a form of cep. Hell we call it a “message stream”.

    How could anyone think it’s not messaging?


  • http://gorodinski.com Lev Gorodinski

    “An event store is a queue”

    This isn’t entirely valid. Making EventStore a queue is what the referenced Twitter conversation is about. It doesn’t currently provide queuing support because it is up to the subscribers to maintain their position in the stream. Making EventStore support this would be quite straightforward and then supporting competing consumers from there wouldn’t be much more – it would effectively be something akin to Kafka.

  • http://blog.peterritchie.com Peter Ritchie

    Events are messages…

    An event store is a data store of events (messages) that can be “replayed” or retrieved in order–that’s a queue, by definition. It’s not a general-purpose “message queue”, sure; but it’s still a queue.

  • http://www.allthingsdork.com Jeff Smith

    There’s always an “anti” group it seems. Sometimes it leads to better implementations and then sometimes it just de-rails the community for a little bit. :-)

    Love your point about not hanging on terms and identifying patterns.

  • asd

    I like to view an event store as a non-destructive database.