What durable EventStore implementation guarantees StreamEventProcessor correctness?

Hi,

We are currently starting to integrate Axon Framework in some of our applications, replacing a custom rudimentary eventsourcing library. Our applications currently use Azure CosmosDB Mongo as datastore. While reading Axon documentation and searching the web I have seen various cases that indicate MongoDB is not ‘a good fit’ as Axon EventStore implementation ( The case for Axon Server over MongoDB for your event store.

The most worrying aspect for the organisation I’m working for is that it is unacceptable to miss events, tracked by streaming event processors, risking inconsistent/invalid system state. Based on the blog referenced, it seems this risk exists for the MongoDB implementation.

Therefore, I wanted to ask: what are the existing implementations for Axon Framework 4 that guarantee to never miss events?

The motivation is that we want to prioritize (eventual) correctness above other non-functional requirements (performance, efficiency, …).

Thanks in advance

Best regards

Ruben

Hi Ruben,

thanks for the message. It sounds like you operate in a mission-critical environment. In those environments, I very strongly recommend Axon Server. It’s designed for this purpose, has features to maximize HA and DR and makes sure all events are always delivered in a consistent order. No gaps, no overtaking and no missing events, ever.

Any other solutions will come with compromises.

Mongo-like databases have very nice flexible query abilities, but lack the concept of ordering which is necessary to use it reliably as an event store.

Relational databases are by far the second-best in class. But be careful. The price-tag on the box may make it seem cheap compared to Axon Server, but it will require some optimizations and most likely more beefy hardware than an Axon Server based setup would require to reach the same performance.

Relational databases will also have some ordering challenges. Insert-order and commit-order are not identical, which means Axon Framework must do some bookkeeping to keep track of potentially uncommitted positions. This does give a window of opportunity of missing events, albeit a very small one. Correct configuration might be crucial here, if the default aren’t correct.

I hope this gives you a bit of insight.
We’re happy to help you work out a business case to see what’s best for your situation. Let me know if you’re interested in that.

Thank you for the explanation @allardbz. I’ve forwarded your conclusion to our technology architect.