Member-only story

Event Sourcing: why using a message broker is a bad idea

Diogo Machado
6 min readApr 2, 2021

In Bali a bath in Pura Tirta Empul is a Public Event

I’ve seen many implementations of Event Sourcing that use a message broker to publish events to the read models. I’ve used that pattern and contributed to ES “frameworks” that implement that pattern. I think It is a bad idea. I’ll explain why:

1) Writing to the event store AND publishing events to a broker needs to be atomic. In most cases a distributed transaction using two phase commits is not an option. We need to create some mechanism to deal with faulty connections between publisher and broker:

To reliably/atomically update the event store and publish events to the broker, we can use the Transactional Outbox Pattern:

https://microservices.io/patterns/data/transactional-outbox.html

The outbox pattern uses a message relay process to publishes the events inserted…

The author made this story available to Medium members only.
If you’re new to Medium, create a new account to read this story on us.

Or, continue in mobile web

Already have an account? Sign in

Diogo Machado
Diogo Machado

Written by Diogo Machado

Software architect/developer. Developing software on the shoulders of giants.

Responses (9)

What are your thoughts?

What about putting Kafka in the game ?
Or after the event store or as the event store ? Does it help ?

Interesting proposal for polling and yes agree that it will cut out some of the complications of broker and ensuring messages are delivered and in order etc.
This idea does do event sourcing, but what about event driven architecture? I guess that is…

I totally agree with that. It is eventual consistent anyway. A second delay is kind of expected. The infrastructure is much easier to achieve and maintain.