Pragmatic Event Sourcing

Event sourcing is an architectural pattern; it’s not a silver bullet

Photo by Mathyas on unsplash

Having successfully built multiple systems using event-sourcing patterns, I have also encountered cases where people have complicated their architecture in the name of event sourcing — an inevitable consequence of being dogmatic about patterns instead of being pragmatic.

This article aims to help you understand that event sourcing is just a pattern that could have multiple implementation variants based on different problem domains and contexts.

I will also try to show you that you don’t need fancy frameworks or libraries; you only need the necessary inspiration from the pattern. You can look into a few reference implementations to borrow ideas but build your system pragmatically and make relevant decisions to your problem domain and context.

In the second half of the article, I will share my thoughts on some common questions that emerge while architecting systems based on event sourcing. I believe this may help you make better decisions in your implementation journey.

Note: If you have never heard about event sourcing, I recommend you read a good introduction elsewhere before reading this article.

Introduction

The way I view architecture, in general, is heavily influenced by Christopher Alexander’s work on patterns and pattern language, which is a philosophical view of patterns and their significance in architecture. Here’s a quote from the book:

“Each pattern represents our current best guess as to what arrangement of the physical environment will work to solve the problem presented. The empirical questions center on the problem — does it occur, and is it felt in the way we describe it? — and the solution — does the arrangement we propose solve the problem? And the asterisks represent our degree of faith in these hypotheses.

But of course, no matter what the asterisks say, the patterns are still hypotheses— and are, therefore, all tentative, all free to evolve under the impact of new experience and observation.”

In essence, we shouldn’t confuse patterns being a rigid implementation strategy — patterns are not concrete solutions to a…