Event sourcing is not new - the prase that you can hear on most of the talks delivered by Greg Young, the “father” of CQRS. People were using ledgers to ensure the correctness of their record for ages. Suddenly, this pattern got popular, when developers for infrastructure components to store pieces of data in what we now call streams of events. Larger players like Netflix started to share their stories with this technique and that definitely spiked the interest among the community.
With this spike, tons of questions came up. Does an event-sourced system need to be eventually consistent? Are we making decisions on stale data? What to do with users that panic when they don’t see something that they have just created, or updated, on the application screen, because the read-model hasn’t been updated yet? How to solve race conditions on the write-side? Can we use a message broker for projections? How in this world can we scale projections, if events must come in order? Finally, nearly all Actor Model frameworks have streams and event-sourcing built-in, for what purpose?
A lot of confusion lead to a lot of failed attempts to use this brilliant pattern, a lot of angry articles from good developers that tried and failed. So, is event-sourcing is just another hype and in reality its complexity and all those issues associated with it overweight potential benefits?
Let me show you how I implement Event Sourcing in real-life projects as part of my daily work. We start by looking at a very simple, yet properly working event-sourced application, which is built with Domain-Driven Design principles in mind. Then, we look at some of those issues that are mentioned above and see how they can be solved. Finally, we get a quick look at how actors fit in all of this and when we might consider using the Actor Model for an event-sourced system, and how it can be done in code.
There will be a lot of C# code in this talk. I will use EventStore as the persistence and Proto Actor to show how to use the Actor Model.

There will be a lot of C# code in this talk. I will use EventStore as the persistence and Proto Actor to show how to use the Actor Model.