I’ve recently finished reading Real-World Event Sourcing. It was a fun reading, but I found the book unclear on a very specific point and I want to express my thoughts on it in this blog post. I may have misinterpreted the author’s explanations but this doesn’t invalidate the following reflection. How to define an event stream? As the book is about Event Sourcing and CQRS (Command Query Responsibility Segregation), events are naturally the central building block: they’re used to store states and trigger effects in the system.

In my career, I had (and still have) many opportunities to develop UIs on desktop and web applications using various technologies. With these experiences I’ve been using two main patterns: MVVM (Model-View-ViewModel) and a Reactive approach. In this post, I want to talk about the Reactive approach and especially about two features where it has become a burden to me. What I mean by Reactive I am not talking about a specific framework here.

In a previous post, I’ve mentioned I’ve read the book Programming Elixir 1.6. As I was planning to read Real-World Event Sourcing, I chose to conduct a second reading because my limited knowledge and skills with Elixir were eroded over time. I took time to take many notes which are available on a dedicated repository. In this post, I want to present to you the Elixir language, the Erlang VM and give you a taste of why you should learn it even if you will not use it in production.

A few weeks ago, I’ve published a post where I described improvements for various architectures, following a logical path from a CRUD architecture to a CQRS/ES implementation. Since then, I participated in Lyon Craft 2025, a local conference focusing on the software craftsmanship mindset and practices. For this edition, we had the pleasure to invite Jérémie Chassaing for an event-sourcing workshop. I had the opportunity to discuss with him and attend his workshop.

When writing software, we’re using types to represent the information we’re manipulating. Values are express through primitive types like bool, int or string. We’re building complex data representation by composing these types. This composition is done by defining our own types, usually with classes or tuples. Even if there are several ways to store and represent the same information, these ways are not all equivalent. Some are too permissive and allows states that should be considered as illegal regarding our business rules.

To develop software, as developers we have to choose between several architectures. Our choice must be based on various constraints like the type of problem we’re trying to solve, but also the load or the level of reliability and resiliency targeted. We also have to consider the available skills in the team. In this blog post, I want to iterate through several back-end architectures I’ve encountered and used during my career.

Few months ago, I’ve read this article: How We Built a Self-Healing System to Survive a Terrifying Concurrency Bug At Netflix. What I loved is how unconventional the solution was. However, unconventional doesn’t mean irrelevant, their solution kept the software running during the weekend, and this without any human intervention. The solution wasn’t perfect, but it was “good enough” and even more, respectful of people’s time. By the end, it concludes with a concept that somehow inspired me: “technological adulthood”.

Recently, Antoine Caron published a blog post about his AI usage. Thanks to him, I’ve discovered the /ai ‘manifesto’ and I want to do the same here. Maybe you’ve reached this post by typing /ai in the URL. My posts All the posts in this blog are written by myself, I don’t use any generative AI to produce content. Creating a blog post is an interesting activity, it requires me to challenge and organize my thoughts before trying to write on a topic.

In early 2020, I’ve read the book Programming Elixir 1.6. At that time I had one goal: to have an introduction to the actor model with a language that supports it by design, in this case Elixir. I think it was a good read and I achieved my goal, even though I didn’t feel able to design a complete system using this pattern. However, I realized I’m using some actor model concepts for a few years now.

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.