If you’ve already developed a software using the event sourcing pattern, you’ve probably faced difficulty: How-to design good events? What is a good event granularity? Indeed it’s difficult to produce good events that will not harm our design. As a seasoned developer with event sourcing, I’m still struggling with this, even if I’ve developed several heuristics over time. In this blog post, I will share with you these heuristics. But keep in mind this is not some kind of best practices.

Nowadays, most of the services we’re using are online and available 24/7. If, like me, you’re working on a company that provide this kind of service, you’re probably aiming for such availability. As I’ve already highlighted it, it has a huge influence on how you should code and deploy your software. Indeed, to maximize availability, you’re probably aiming for a zero downtime deployment. Zero downtime deployment includes several topics. Today I want to focus on how to achieve a database migration without service interruption.

I’ve recently gave a talk with my friend Aurélien about the heuristics we’ve developed after using CQRS/ES for several years. After our talk, we had a chat with some developers. We concluded that choosing a state-based oriented approach (like CRUD) seems to be the default solution, such choice seems to remain unchallenged. On the opposite side, choosing an event-based systems (event sourced or event driven) will very often be heavily challenged.

I had the chance to work few months in Agicap, an enterprise producing a cashflow management SAAS for businesses. It was a great mission, my team worked a way that I consider to be, so far, the most efficient and pleasant in my career. We managed to produce value at a constant speed while keeping a full control of our code, not allowing any kind of quality depreciation over time.