Making the message bus reliable

[Arseniy-Popov]

I wonder if the message bus used in production at MADE is different from the one described in the book in ways which make it more reliable. In the scenario of a batch quanity change deallocating a number of order lines, if the service dies after a batch quantity has been changed, but before the order lines have been allocated again, they are going to end up unallocated as events are not persisted.

One way of rectifying this that I see is writing events to a message broker, perhaps using a transactional outbox, to a channel internal to the inventory service, to be later consumed by the same service. Another way is writing events to a database and having a poller querying the database and consuming events from it as one of the entrypoints into the service.

Both this options seem to nullify the need for the message bus by replacing it either with a message broker or a database as the place where events reside inbetween being processed. So I wonder if these approaches are feasible at all and what your thinking is on how an in-app and a persistent message buses compare.

If someone apart from the maintainers wants to chime in on this, please do!

[dbaber]

I think in the Epilogue they talk about this and they use EventStore.

[georgek]

Why not process the whole message bus in a single unit of work?

[hjwp]

it depends what you want really. after you finish processing one event, you have to decide whether you want to commit and persist your changes, or if you want to move on to provessing all the other events that may have been generated (and the ones they generate, and the ones they generate...), and then decide if it's ok that an error in one of those downstream events causes your whole transaction to be rolled back. it really depends on how independent they handling of each event needs to be, from a business perspective.