Event Sourcing for better observability

Small Talk with Oskar Dudycz

This blog post is the transcription of the chat we had with Oskar Dudycz about his Event Sourcing workshop on 12 February 2025.

The conversation has been slightly edited to better fit the written format. Enjoy!

Avanscoperta: Would you tell us something about your upcoming workshop and what is it?

Oskar: I’m a huge believer that event-driven architectures and event sourcing can bring a lot into the game, like observability - both technically and from the business standpoint - and also a good synergy in reflecting our business domain requirements into our code.

I’ve been doing that for many years, starting as a regular developer, architect, manager, etc., and I saw those benefits in my projects. Working on the tooling, such as EventStoreDB, Marten, Emmet, I gathered a lot of experience, and not only good one… We were even joking before going live that you cannot always be the best version of yourself.

That's also why I started doing those types of workshops—to help people get started quickly, be more productive in event sourcing, and reap the benefits that I mentioned.

I always think that the best way to learn is to learn from your own mistakes, and that may be the best type of learning, but I don't think that this is always the fastest way to learn.
If at least one can learn something from my mistakes and past projects, then that type of workshop can smoothen this journey because, unfortunately, event sourcing is too often pictured as a complex or even complicated way of building applications. I disagree with that. I know that it can be like that, but it doesn't have to be.

And that's what I want to show during the workshop. We’ll be doing this very hands-on. For most of the workshop, people will get their hands dirty in code and build their own application from scratch. Of course, we start from a simpler application, but it's still quite real-world, and I think it could be a good starting point for including that in their projects or maybe at least to have fun. That's also important.

Avanscoperta: We already anticipated that the workshop will be extremely hands-on and with a particular focus on coding. At Small Talk we always go with the basics first, so we just discussed what the workshop is about.
The next questions is then about event sourcing. What is it? Why should one care? Why is it so relevant today in your opinion?

Oskar: Event sourcing is a storage pattern. It can be seen in a similar category as relational way or document way. And each type of storage has its own benefits.

The biggest benefit of event sourcing is that you are not losing the business information.

It works like this: we are making decision, such business logic or like regular “if” in our code, and then as an outcome, instead of just overriding the current state, we are storing additional information, additional facts, which is called event.
In event sourcing, the name comes from the fact that events are the source of truth. So there is no other state.

For instance if we are modeling the guests’ stay in the hotel, then we can record events like “guest checked in”, “night state charge recorded”, “spa payment made”, “guest checked out”. So all of those events are representing a specific fact that happened during the business workflow.
And most of the time, in our industry, we had to optimize for the storage size. And because of that, relational databases with normalization and the possibility to reduce the size of the data to not repeat all that information were really popular.

Nowadays, data storage is relatively cheap, but the information is priceless. So the more we can keep this business context, the more we can make better decisions and get better insights from our business workflow.

I really love the sentence by Anita Kwamme is that:

event sourcing is architecting for the tomorrow's questions.

I'm really jealous that I didn't come up with the sentence on my own.

Avanscoperta: So who is this workshop for?

Oskar: This workshop is definitely for engineers. It will be a very hands-on experience.
It’s probably aimed for people who already did some application, such as web API, or they did some business logic, etc., but you don't need to be an extremely skilled developer.

You might be still a junior, you might be an architect also. As long as you can write simple code in C#, Java, or TypeScript, you should be fine.
I will be introducing all the concepts from the beginning, and we will be doing a gradual step-by-step learning experience.
I think that this approach is also good for the people that already are doing event sourcing because it's a good chance to ensure that you didn't miss something.
But as you know, each group has its own dynamic. So if the majority of people are more experienced, then we can go a bit faster.
In general, I'm always trying to ensure that no one will be lost during the workshop.

Shall I share my screen for a second and show how the exercises will look like?

Avanscoperta: Sure, we said we don’t have slides at Small Talk but screen sharing is always fine.

(You might wanna check out the video on YouTube for the screen sharing part, from minute 10 more or less.)

Oskar: As I mentioned, we’ll be working with Java, C# and TypeScript, and we will have the same flow.

But as you see, we will be going from the events definition, then how to get the state from events, how to append events, how to run the business logic, how to build the the application logic and then also read models, etcetera.

And just to prove that no one will be lost, for instance, this exercise starts with basic modelling and putting in code your events, so not much there. But then the next exercise starts with the solution of the previous one.
The exercises are not so important on their own, but they are built in a way so that they are polished throughout the years that I've been doing this workshop, so I'm putting some places here and there to trigger the discussion.

The most important thing it's not coding, it's learning through coding.

I believe that for this type of workshop the more hands-on the better because then you will see that it's not that hard and it's not that scary. At least that's my idea behind it.
And of course we will be doing some sticky notes and basic EventStorming because how can we not do it if we are here with Avanscoperta?
But jokes aside, that approach really plays well with event sourcing because both have the idea of making it easier having proper discussions.

Avanscoperta: So we just got the big picture (pun intended) about what we’ll be doing in this workshop - there will be code, Miro, screen sharing, group exercises, etc.
One thing I really liked is your statement about “it's not about coding but about learning through coding”.
Of course we are all fans learning by doing and all of that, but if there is some help from someone who already made some mistakes and can ease the learning process somehow, that's really cool.
And also the learning through coding idea is really effective and I believe folks will like it, especially because we are also targeting people who we can classify as beginners or juniors, as well as folks who already know what to do, but maybe need some refresh or want to see other perspectives… because learning by coding means talking to other people that are exactly like us.

One thing we like to do with our workshops is to keep them in the range of 12-16 people, so it's not like everyone is sitting in front of their screens watching slides or Oskar talking with their camera off.

In a nutshell - it will be extremely interactive and therefore each one of you coming to the workshop will have an active role in this.

Oskar: All the exercises are intended to be short and I don't expect any one to complete all of those exercises because that's not the goal. The goal is to understand each concept and that's not only by solving 100% this coding exercise. That's something that you can do and repeat on your own time, but this is just to show practically how that works and having a proper discussion, asking questions and having those questions triggered, because I really believe that coding is also a form of design. That's at least how I see it.

Avanscoperta: Each of our trainers has a story of either solving problems, at one point being asked to do something, or just feeling natural about starting to teach. So, how did it start for you? Why are you doing this workshop?

Oskar: Somehow I always wanted to teach, maybe because my father and my grandparents were always telling me that I should help others to learn and sometimes I was even helping during like a primary school my friends.

I really struggled with event sourcing at the beginning. It started with reading so many articles, watching all of Greg Young's talks, etc. It was eight or nine years ago, and there were way fewer resources compared to now.

Then I finally got the chance to use event sourcing in my project and I thought, “This is my moment”. I started to design and work on this application and I realized that I have no idea what I'm doing. And my first thought was, “This event sourcing is terrible. Why did someone invent that?” But then I thought, “Okay, so many smart people are doing it, then probably that's something wrong with me”.

I'm somehow a grinder. I do not necessarily recommend being that type of person, but I always try to push myself to at least ensure that I'm not doing something wrong. So then I started to learn and doing small exercises, and sharing that in public.

I also started to be more active on Marten’s GitHub at that time. Marten is one of the tools that I eventually co-created in a .NET space for event sourcing, and I saw that people were having the same issues that I had.
And I started to answer them with the solutions that I found. And those solutions were helpful for the people.

Step by step, taking baby steps, I realized that maybe my journey, my findings, and my knowledge about the tools could help other people to make it easier.

Plus, I think it was also some kind of challenge for me because in my projects, I saw that event sourcing doesn't have to be that hard or scary.
It's also kind of addictive that when you start to do that and you get your “aha moment,” you just want to continue doing it. So maybe I wanted to show people that it doesn't have to be as it is mostly pictured. So it was a mix of all these reasons.

In the end, as I was maintaining Marten for a few years, I was working at EventStore, now called Kurrent after rebranding, and I also built Node.js tool Emmet. So I also wanted to teach people how to use those tools correctly.
So that was my main motivation. But I just truly believe that event sourcing should have wider usage. It is a niche approach, but it should be a much broader niche, and not this small, because it can help many projects.
I'm not in the team to say that you should do every event sourcing in all possible places. Definitely, there are many places where it can be extremely useful and people can benefit from that. But not all the places.

Avanscoperta: So what are those places? Where is event sourcing a game changer?

Oskar: We’re talking about places where we have business workflows that are maybe a bit more complex than two or three steps, or workflows that are just important from the business perspective. This extended tracing where you’re not losing any information is super helpful.
I think that in general I don't see a domain where it couldn't work but definitely those that are related more to processing workflows etc - they are definitely useful.

Most of the time we say that financial domains are really great for event sourcing because event sourcing works as accounting.
I even heard the joke that Hammurabi invented event sourcing when he invented the first accounting stuff.

Avanscoperta: It sounds like a DDD Borat joke.

Oskar: That could be… I don’t remember who said this, maybe Greg Young… but it might have been DDD Borat too.
Definitely financial domain is an obvious choice, but I wouldn't just lock in event sourcing in that type of domain.

I see it working in many medical projects because it works well when you need to have this strict audit log and, in general, when you have areas of your system that can benefit from getting more insights from your data, and business workflows.
It always works well when you have engineers and a business logic that looks like a state machine. These are the places where event sourcing is a really good candidate.

Avanscoperta: What are the biggest factors of resistance when folks want to start using it, or introducing it in their company?
One is to do it for your project or within your small team, but we talked about finance or medical, and you know, of course, we are not probably talking about the whole hospital or what's not, but definitely a few departments.
So why is it difficult, if it is difficult at all?

Oskar: There are multiple factors. As Gerald Weinberg said, “Mostly it's a people's problem”, as everything.

Of course, I don't want to say that people intentionally don't want to use event sourcing, that's not how it goes. But as I mentioned it is a niche. So many people just prefer to choose the boring tech stack, which is a good decision in general, to just stick with your favourite tooling. On the other hand, too often that's also a limitation because you might not benefit as much as you could from it
And the knowledge about event sourcing is not spread enough, so there are not enough people uh teaching about event sourcing and writing about it.
It's changing, right now we have much more than when I was starting but it's still a matter of lack of good resources, but it's getting better.

The other factor is that event sourcing for many years was pictured wrongly.

Instead of focusing on streamlining workflows, representing your business workflow in code, registering all your facts and making decisions… for many years it was somehow conflated with stuff like messaging and Domain-Driven Design, and I think for many years it was shown like the highest level of enlightenment, which is kind of a joke, such as, “First you need to learn everything about DDD, then everything about distributed systems”, etc.

And because when people were looking at the resources about event sourcing, they thought, “Okay, that's really cool, but I won't ever be that smart, or I won't ever have such a big project to work with event sourcing”, I think that's a false narrative because event sourcing can be really accessible.

Event sourcing brings a lot of fun and makes many things even simpler but we need to approach it with an open head which means that we need to unlearn some stuff and some past ways that we were doing. If we don't do that, then try to apply each of those past techniques won’t necessarily work well with event sourcing.

For the person who is seeing event sourcing for the first time, getting all this buzz, and understanding its potential, it's hard to filter out what you don't need at the beginning, when to apply specific techniques, etc.

That's also why I'm doing this workshop, I want to show a simpler and more pragmatic way to share and use the knowledge about event sourcing.
You can also learn things as you go, starting simple and then adding stuff from DDD and from distributed systems where and when you need it.

Avanscoperta: What is the pain point we are aiming to solve with your workshop? Why should folks come along?

Oskar: The pain point business-wise is observability, easier debugging, easier testing, and understanding complex systems. Event sourcing can help in that.

So who should join? I think “everyone”, but that’s a bad answer.
Definitely, folks that are starting or started their way in event sourcing. If they want to get started, if they’re doing it already, if they want to make sure they’re not missing anything and they’re on the right track, or they want to learn more about tools like Event Store DB, Marten, Emmet, then that's a great way to do it.

This also appeals to new people, because in the current shape of our IT industry, you need to somehow have knowledge that is an outlier to the other people, and in my opinion event sourcing can be such thing, because even though it is a niche, it's growing and boiling underneath the surface.
Knowing this event sourcing pattern, even if you currently are not using it in your project, can also be an important aspect and eye-opener. Also, I will be touching stuff like CQRS, vertical slices, event-driven architecture, and business workflows.

There is also an overlap with the traditional way of building applications.
If someone is interested in this area, then that can be also a good way.
For those who know me and are curious about how I do things, this workshop is the outcome of my personal journey.
But it won't be only biased because I will show different ways and different flavours of how you can do stuff.

Avanscoperta: As we close for today, I also wanted to briefly touch on your career, if we can call it such, as a writer. I’ve noticed your consistency, and that's really cool. How does that work? What keeps you motivated? When did you start, and what feedback have you been receiving?

Oskar: I’ve always liked to write. I don't know why but I always like to write. I like to do creative stuff, and that’s also why probably I like coding.

I started blogging quite a long time ago, probably 12 years ago, and I was writing my Polish blog, but at the beginning and for the majority of my, as you said, “blogging career”, I wasn't that consistent. I was just blogging once or twice per year, but what helped me is that instead of thinking about what great stuff I could write and what great stuff I could provide some information about, I inverted my thinking about blogging.
So I said, "Okay, so this is Friday, and I would like to write something every week." So let's say that I have six hours right now on Friday, and instead of trying to build a really great, huge article, I started to think about what useful things I could write about within that time.

Instead of trying to invent something, I started to search for what questions I answered and what interesting stuff I did, and it doesn't have to be something extremely innovative or totally brand new.
If someone asks you how you do a certain thing and you manage to help that person, then there's a high chance that there are more people like this one who can also benefit from it. Even if someone else wrote about it and showed a better way, then this is your way.
If someone would like to start writing, then just write for yourself. I'm writing because I forget things, so really you never know.

I wrote some articles that I thought were some of my best ones, actually not many people read them.
Some that I just created within two hours where those that are most read.

You never know, you won't ever guess who will be reading it. But if we build this consistency, maybe it doesn't have to be every week, maybe every other week, every month… but for me, this inversion helped me and in the meantime, I also started to do this - when I'm discussing with someone in some chat and I help them, then writing what we discussed about somewhere in a private GitHub orin a Notion page, or somewhere else… then if you gather many similar answers like that, then it can be already a good starting point for a blog article.
That would be my advice.

Avanscoperta: Basically it's a matter of documenting what you've been already doing, rather than reinventing the wheel or trying to come up with a shiny new incredible thing every time.

Oskar: Indeed. I noticed that many people are struggling with this, and I was also struggling because I had this idea that I think it's great, but then when I sit in front of the computer, I realize that I won't ever make it today.

Plus, the good thing is that at the beginning, no one will read what someone just started writing. And that's a great chance to make mistakes and write something wrongly.
You can always amend it and change it.

Check out Small Talk on YouTube or Spotify.

Credits: Picture by Christian Holzinger on Unsplash.

Learn with Oskar Dudycz

Oskar is the trainer of the Practical Event Sourcing Workshop.

Check out the full list of our upcoming training courses: Avanscoperta Workshops.

Let's stay in touch! 😊

Subscribe to our Newsletter 📩 and be the first to know when we schedule a new workshop or we publish a new workshop.