7 Lessons learned about Event Sourcing in last two years
And how to avoid learing them the hard way
#1 Consider going for event sourcing multiple times
Event sourcing and CQRS are very apealing concepts for many architects and developers. The problem is that it’s often stated as requrement before real design process begins. Not all project will benefit from this aproach so it’s very important to think about implementing event sourcing only when you really know you need it.
Attempts of applying event sourcing principals to some of the projects will result in more problems than the real benefits. Thin of event souring like of radioteraphy — it’s very good threatment for particular cases but very damaging when used in an incorrect case.
If you can answere at least some of the following questions with YES, then go ahead and consider using event sourcing, if no — drop this idea.
- Are your entities express behaviours that involve a lot of important delta changes (increase balance, lower price by 20% etc).
- Are you dealing with money?
- Do you need extreamly detailed audit logs?
- Do you need the ability to revert some of the changes easly?
- Can you deal with eventual consistency?
- Do you have a big budget?
#2 Do not reinvent the wheel
This one is quite obvious for almost all cases but especially important when it comes to event sourcing. Some of the concepts like event versioning were in our initial opinion not so important despite what rest of the community was saing. Only after wotking for a while on an event sourced project we have fully understood the importance of all of the concepts that are involved. Some of the smartest software architects came up with the idea of event sourcing and those guys knew what they are doing.
#3 It is not all or nothing
Use of event sourcing shouldn’t be considered as a solution for the entire project. In a majority of cases, one domain will benefit from it and rest can be implemented using more conservative approaches.
The same goes for CQRS approach. You don’t have to apply it to all the modules of the system, just to those that need it.
#4 Don’t go with Apache Kafka as event store
This one is strictly infrastructural but very important nevertheless. Kafka is great, but not as a store. It dies under moderate loads, eventual consistency is transformed into nonexistent consistency and servers are sweating way too much.
Use it to publish events, store them somwhere else — traditional, relational database works great by the way.
#5 Involve UX designers in the process from the begining and let them know what event sourcing could mean for them.
Event sourcing alone has little to no impact on the UI design. Contrary to eventual consistency and the fact that you cannot rely on the classical response from the server.
Your design team needs to factor those things into the final project. Users need to be aware that some of the actions will have delayed effect and sometimes when some error occus they will be informed about this later. Make sure that all of the edge cases that user can encounter will be handled by the UI properly. The same principal applies to all CQRS apps.
A good example of such UI (in this case most likely due to using of a large distributed system, not event sourcing) is Google API Console. All of the actions conducted by the user are queued and their status (pending, ready, error) can be seen in one place in the UI.
#6 Don’t forget about concurency handling
Concurrency issues and solutions to them need to be well thought through. The action that is triggered because UI allows it can, in fact be forbidden when the event hits the store.
#7 Think, rethink, and grab as much knowledge as possible before coding.
Make sure that you have studied all case studies that you can find that relate to what you are doing. Design everythink on paper first, implement fast and dirty proof of concepts and discuss everything with everybody that understands the topic. You need to be 100% sure about every decision, every assumption. Event sourced projects are long, difficult and changing concepts in advanced stages of the project can be expensive.
