Event Sourcing Explained — Why You Should Care (Part 1)

With this series of posts, I will try to shed some light on the original idea behind Event Sourcing and how we at Serialized think about it. I will also try to distinguish the technique from other similar architectural patterns and solutions that involve events. Finally, we’ll get to how we can implement an event-sourced system and also look at some possible pitfalls and how to avoid them.

In this post (part 1) I will try to describe the fundamentals of how Event Sourcing works and why you should care about it.

Event Sourcing vs. Traditional Systems

When performing what we call transactional tasks, which might for example be to place a book in our shopping cart or place an order, we can see some fundamental differences between more traditional systems and an event-sourced solution.

In a traditional approach, transactional use-cases usually involve persisting data in a few SQL tables or a NoSQL database. When the changes are performed the data in the database is updated to match the new state.

This works but what is not obvious is that we’re losing information by updating our model. For example, there’s no way of knowing what the customer had in its cart before changing it, or at which point in time the contents changed. We could solve this by storing this extra information about the modifications in supplementary data structures, but once you go down that road, it’s easy to bloat the model and the solution quickly becomes quite complex.

In an event-sourced solution, we instead look at the world as a sequence of events that occur, and save these events as is. These events contain facts about what happened at a point in time. The events are appended to an ever-increasing log of events and once an event is saved, we never modify it.

When it comes to naming events it’s very important to use words from the problem domain, without mixing in technical terms. If we manage to do this, the event log can be really useful, not only to developers but to all parts of the company. We also name the events in the past tense, to emphasize that they represent something that happened and will never change - since we still have not invented the time machine.

Why Event Sourcing?

At first glance, only adding events to a log might seem impractical. However, looking closely at mature domains such as accounting, medical, finance, and insurance you will find that they have been using Event Sourcing for a long time - long before computers were invented.

Doctors keep track of your medical history by adding to the end of your journal.

An accountant never erases anything from the books but rather always adds new transactions, regardless if it’s a "fix" for an incorrect previous transaction or something new.

Think about it, why do you think doctors and accountants work this way?

Events Are Everywhere

To record events is the simplest tool we have for remembering what happened at a certain time. It allows us to use our natural language without letting technology take too much space.

This is also a reason why the modeling technique called Event Storming has become so incredibly popular. We can take the outcome from an Event Storming session and implement it directly in an event-sourced system. If we would use a traditional relational model (or document/key-value store for that matter), we would have to translate our knowledge from the Event Storming and the intent would likely get lost along the way.

Why Delete Possibly Important Information?

The event-sourced model brings great power over time. A doctor will always have all the historical information in the patient’s journal, which is very useful when diagnosing the patient.

Imagine if all information the doctor would have would be your current state of well being - without any history. Of course, his/her job would be so much more difficult without being able to look back at your medical history.

You will never know what data you might need in the future or what questions will come up, so keeping the history of events is something that can be extremely valuable to your future business.

Yes, we know about GDPR and the issues with it, and we have an upcoming post about our thoughts about it.

Time Matters

Since all events are stored in a log that is a timeline, we get modeling of time for free. This is important since it makes it possible to answer questions such as: How long does it take for customers to pay a ticket after it has been booked? To answer this, we can just look at the time between these two events, we don’t need to change our code in any way.

Auditing

Mature and serious domains have high regulatory demands on auditing which you can get automatically when you log everything that happens. By adding the information about the user you will always be able to answer the question of who did what and when in the future.

Know What the Hell You’re Doing

Finally, the comforting feeling of always knowing how we got to where we are is something that is really nice. If you or your team ever tried to find a bug in a legacy system that was built on top of a relational database, you know that questions can sometimes be impossible to answer. If you’re using Event Sourcing, you’ll never have any issue answering the question of what has happened and when it happened.

Summary

To summarize, Event Sourcing brings you:

• Less technical mumbo-jumbo and more domain language in the solution
• An audit trail for free
• No risk of losing important business information
• Possibility to draw new conclusions on historical data
• Full understanding of what the system is doing

This was a summary of the fundamentals of the whys of Event Sourcing. I hope you’ve found it interesting!

In part 2 of this series I’ll give my views on some important concepts that I think are useful in order to succeed with Event Sourcing. I’ll also try to bring some clarity to the difference between Event Sourcing and other architectural styles that involves events.