There is also some microservice specific information with regard to databases available on: Microservices

CQRS and Event Sourcing

Greg young has a nice video on CQRS and eventsourcing. I wrote an article about Where business logic isolation fails with RDBMSses and an ex-colleague and friend of mine (Alexandre Gravem) pointed that if you’d go with event sourcing, you shouldn’t have to worry about whatever happens to your data, since you keep track of state and if you need to know what has happened, you load an older projection of the state.

I have implemented this 2 times in different systems now and although it seems very intuitive and sensible (it absolutely is by the way) it also comes with huge downsides, all very hard to do when you (as a company) are still relatively small. There’s so much related work to be done and questions to be asked, it’s often killing a mosquito with a bazooka, especially during startup phase (that shouldn’t be an excuse to not gather the data anyway).

This video does not provide an answer to the blogpost I created. In addition, SQL-projections of event sourced data-repos don’t actually have to perform relational integrity (e.g. by constraints) since this is done in the code that puts the mutations in the database, and therefore all logic goes back to the businesslogic talking to the data-repo.

Event sourcing can only tell me, given an entrypoint and a subject (which are also hard to define matters, because you will have to achieve a new normal state on the definition of the subject, including the payload of the change) what needs to be done to revert these changes. It cannot tell me if I MAY revert these changes, and which other entities where using my data, and how they will benefit or fall by applying an inverted delta to the event-log.

Despite that, event sourcing is a great thing to know about and have in your bag of knowledge. Whenever you need to create some financial, stock-related or other system where you need to remain able to tell exactly how the numbers came the way they are, you’ll think of this one.

Relevant when:

• you need to store the entire history of why numbers became this way
• you want to be able to see data in a specific timeslot
• you need absolute checks of your algorithms to prevent regression at all cost
• your data is susceptible to fraud