Not sure which term to use "Database" or "Event store" but I'm talking about where we store our events. I wonder if Event store should have ACID properties, especially the Atomicity. What I mean by that, should we be able to rollback the state, in case of errors, by removing saved events. but that would break the law of event sourcing which is "event must be immutable". I'm not sure how this kind of database are implemented, but if we are unable to rollback does that mean we have to manually make a compensation action for each transaction?
Asked
Active
Viewed 23 times
1 Answers
0
A in ACID means Atomicity, and not the ability to roll back.
The concept of rolling back comes from databases that support transactions across multiple logical data collections, like tables in relational databases. Event sourcing implies that you work with individual streams, and the stream is your transaction boundary. That's, by the way, what connects DDD aggregates to event sourcing in general, although it's not entirely obvious for many.
So, a database for event sourcing should indeed be ACID-compliant, but A would mean that it should support transactional append for a single stream.
Alexey Zimarev
- 17,944
- 2
- 55
- 83