During my series on event sourcing, I got a question a couple of times: “Why don’t you use an event sourcing library? Why have you built your own kind of library?” So part seven is about the trade-offs of using out-of-the-box libraries versus building your own – even today.
TL;DR: Micro-optimizations are not a substitute for design work. They are how you earn the right to redesign. In the Azure Service Bus SDK, repeated work in the Body property first led to smaller allocation fixes. Once those fixes exposed the shape of the problem, a small internal redesign made the code faster, clearer, and easier to reason about. “This code is bad. We should rewrite it.” Most developers have heard that sentence. Many have said it. I have too. The problem is not...
Event‑sourced systems must evolve, and sooner or later, events need to change. In the sixth part of my series on event sourcing, we are looking at versioning of events (schemas) and whether migrating or keeping all old versions is the way to go. Of course, there are trade-offs involved regarding long-term maintainability and overall simplicity.
TL;DR: After temporary allocations were removed from the Azure Event Hubs partition-key encoding path, the Jenkins lookup3 hash loop itself became the next interesting place to look. Tightening that loop reduced CPU overhead, but it also raised the bar for review, portability, and correctness. I like performance work most when it starts with a boring question: why is this small method showing up so much? That question came up while looking at the Azure Event Hubs client. Event Hubs is built for...
TL;DR: Small code paths become expensive when cloud workloads execute them millions of times. The Azure Event Hubs partition key resolver is one of those paths. By removing temporary allocations from the partition-key encoding path, the Azure Event Hubs SDK reduced garbage collection pressure on a publishing hot path. I like performance work most when it starts with a boring question: why is this small method showing up so much? That question came up while looking at the Azure Event Hubs client...
In the fifth part of this event sourcing series, I’ll show you how we use compensation of events to handle failed commands and events that should never have happened. Sometimes, things go wrong – a command fails because the database is overloaded, there is a bug in the code for some edge case, the system is out of memory, the infrastructure misbehaves, etc. Or a user did something that should never have happened, like importing the wrong data set. When this happens, we want the...
In the fourth part of my event sourcing series, we’ll take a look at why long event streams – streams with lots of events – are a problem and what options there are to deal with this problem. Why read models are not always enough to solve performance issues due to long event streams. And of course, I’ll discuss the involved trade-offs.
This is part three of my event sourcing series. In the first two posts, I showed you approaches that rely solely on projections. Now is the time to introduce read models to support all your query needs. And maybe, solve some performance issues as well. Of course, I’ll discuss the downsides of read models, too.
To finish this post, I’ll do a deep dive into a code example.
This is the second post in my series on event sourcing. Last time, we saw a simple implementation based only on projections. While simple, it can only be queried by the event stream ID. In this post, we look at an approach that allows for more lookup criteria while still avoiding a read model.
This is the first post in a series about event sourcing. I’ll start with a very simple event sourcing implementation that is often good enough. Most of our event streams are implemented in this simple approach. In the following posts, the concepts will be extended to match additional requirements. I’ll touch on read models, consistency, long event streams, archiving, compensation, event skipping, lifetimes, and bi-temporal event sourcing. Every post will explain the concepts and our...