Event sourcing

Why should I use event sourcing (or why not)?

As a general rule, I always try to find reasons not to use some new technology rather than reasons to use it. This is probably because I’ve been a victim of overengineering and now I feel really bad whenever a new design ends up costing more than the simple approach. I mean this in the context of a real solution for the real world, not in the context of individual experimentation and learning. If I’m learning something, the more overengineered the better.

For those not familiar with what is event sourcing, the concept is not new at the end I’ll leave some reference if you want to dig further. In summary, it’s a pattern where you store what happened on your application, rather than store the current state of the application. And if you want to know the current state, you can just query all that happened and figure it out.

That said, I would not use event sourcing in an application that does not have an auditing requirement. I also would avoid migrating the architecture of a system that is already working unless there’s a very good reason, like some new requirement appeared that makes the whole system meaningless unless there is the possibility to rebuild the state at a specific time or some very strong auditability capabilities. One thing to consider if a new requirement like this arrives is to use a hybrid approach where you keep the current architecture but also publishes events to an external event broker. Then you can build a new system that reads the events and provides the auditability.

A fitting example is a bank account service. Instead of simply storing “User A has 200 dollars in his account” you would store “User A opened his account” “User A added 100 dollars to his account” “User A removed 50 dollars from his account” “User A is being very annoying with customer service about his 50 dollars” (okay, this last part doesn’t need to be in the database, but man, customers sure can be a bit…)

Do I need to use a event broker like Kafka if I want to do event sourcing?

Short answer is no. This is a common misconception about the event sourcing pattern. The underlying technology is not a requirement for the event sourcing pattern. All you have to keep in mind is that you are designing your application state as being stored as a series of events. Of course you can use a Kafka topic to store your events, but you might as well just use a simple relational database (or even a NoSQL one for that matter). You might even have all the application state in memory and don’t use any database (it’s hard to think of a real life scenario under these circumstances but hey, it’s still possible to do it).

How does event sourcing fit in a hexagonal architecture?

(I’m kind of listing some random questions that can help me make relations between event sourcing and existing concepts which helps me a lot when I’m learning new concepts).

To be fair, there’s no strong relation between both concepts. Hexagonal architecture is a pattern that aims to protect the main part of the code from the auxiliary ones. In that sense, we could consider that the complexity to handle the application state from the events, replaying events and all that, would most likely not be in the application core. It makes sense to have an adapter between the application core and the event sourcing complexity since the event source pattern is just an auxiliary pattern. By auxiliary pattern I mean that there is no direct correlation between application business rule (core application) and the event sourcing pattern. That being the case, I can see an hexagonal architecture where the main application code would have access to an interface that provides the state of the application in a specific time.

So in summary you can use event sourcing in a system that follows the hexagonal architecture pattern if you want, or you can also not use it.

Final thoughts

Event sourcing is a quite simple pattern but a very powerful one. It’s great for auditability and can be somewhat easy to implement. Even though “easy” is not frequently associated with this pattern, the idea behind it is really not that complicated. Of course, if you want to provide everything that the pattern could provide, like replaying events to build state in a specific time in a system that integrates with other systems and the replay of events causes side effects that propagates into the other systems, it can grow complex real fast. It is worth a try (:

Leaving extra sources for:

• What is event sourcing

• Event sourcing examples