TL;DR — Event sourcing is kind of sweet

Part of a series

Next article: I gotta see the goods

Recently I had to renew my passport application, issue is that I make a submission once every few years or so and I’m not really organised so I have to collect all the information required and check that none of my supporting documents have expired. Real pain in the ass, so I decided to build an application for it.

New application, new opportunity. So I decided to try out new techniques and I had watched this talk by Steven Pember about event sourcing. With event sourcing we basically throw out the idea of tables and fixed representations of entities all together: entities are made up of events persisted to an append-only event log. Event sourcing is often accompanied by event driven architecture in the form of Command Query Responsibility Segregation (CQRS). They go well together because each command or query can be mapped to an event and then appended to an event log.

I think a full blown event driven architecture was a waste of beer money so I decided that I didn’t need the benefits offered by event driven architecture and CQRS. Modular monolith instead of microservices was appropriate and while CQRS can be implemented for a REST API, it also makes things more complicated than it needs to be so I stuck to the usual patterns. I used Postgres for the event log, it has pretty good support for querying JSONB columns and everything else in my setup uses it so it kept the infrastructure side of things simple.

Event sourcing offers many benefits, for me it has mainly been the flexibility that it offers (MongoDB is rising in popularity these days because it is so flexible): takes out all the time required to do upfront database schema planning and allows for faster changes to an entity’s schema. In my view we get the flexibility of using MongoDB while also keeping the SQL querying benefits of using an SQL database: we can still perform joins, filter on event data and also place indexes on them if we need to. We also don’t lose any state at all so any change to an entity is auditable. It should also make investigating bugs much easier because its easier to determine whether an issue is caused by the underlying data or application logic because we never lose state.

However, it isn’t without its drawbacks, the issues I initially encountered with event sourcing are:

• There is no fixed representation of an entity, so each time we need to load an entity we have to load up all the events associated with it and determine the current state
• Schema checks which ordinarily would have been enforced database side now become an application side problem. The API still validates requests but there is peace of mind in knowing that the database has an additional check too
• Uniqueness checks for columns become a bit more difficult because the database can’t and we need to run a long winded query
• Checking if a row was deleted also becomes difficult

There are solutions to the problems, its just new ground to cover.