@maarek and @giautm Any input on this approach?

It does come with some downsides:

• Requires MongoDB to be configured as a replica set (which it should for production anyway).
• Requires MongoDB 4.4 to support creating collections inside transactions.

An additional benefit with having a transaction for the event store is that all of storing the events, projecting and publishing can eventually happen inside it. I believe this would also work for other DB backends (PostgreSQL for example).

Hi, sorry for delay.

I don't think move publish progress to transaction is the solution. Because It cause new two problems:

• If the publish progress too long - network delay for example, then the database will lock until the publish success/failed.
• In case the publish success, commit transaction maybe failure. Then, other services will receive the "ghost-events" (Events that's not happened on the source).

Thanks @giautm for the input. I believe you are correct! Maybe some kind of outbox pattern is the way to go then..

Closing until further work has been done on this (probably the outbox pattern).