Adrian Ilie: Wielding the power of Event Sourcing

Adrian is a Senior Software Engineer and Future-Focused Application Architect. Over his +8 years of experience, he has explored his passion for .NET C# and Azure Cloud on top of a secure foundation in agile development and clean architecture.

Join Adrian on October 24^th online, on dotnetdaysro’s YouTube channel for a hands-on demo on full-stack event sourcing. Till then, take a sneak peek at his journey with event sourcing.

Hi Adrian! First, tell us how you discovered event sourcing.
I first came across event sourcing while working with Yves Goeleven, an architect I collaborated with. We applied it in a real-world project, and that experience opened my eyes to how powerful it can be for both scalability and maintaining a clear history of system changes.

What are the prerequisites for using this approach? Can any software engineer use event sourcing?
Yes, any software engineer can use event sourcing, but it requires a shift in mindset. Instead of persisting just the current state, you persist the sequence of events that led to that state. Prerequisites include a good grasp of domain-driven design, understanding immutability concepts, and being comfortable modeling business processes as events. It also helps to have solid fundamentals in distributed systems, since event sourcing often goes hand-in-hand with messaging and eventual consistency.

What’s the difference between event streaming and event sourcing?
Event streaming is about transmitting events in real-time from producers to consumers, usually for processing or analytics. Event sourcing, on the other hand, is about storing the sequence of domain events as the source of truth for your system. Streaming is about moving data, while sourcing is about persisting history. They complement each other: you can source your events and then stream them to other systems.

How does event sourcing impact observability?
Observability becomes much stronger with event sourcing. Since every state change is captured as an event, you have a complete audit trail. You can replay events to debug issues, reconstruct past states, and gain deep insights into user and system behavior. Essentially, observability is built in — logs and metrics can be derived from the event stream rather than bolted on afterward.

What’s your favorite event sourcing feature?

My favorite feature is time travel. Being able to replay events and reconstruct the system at any point in time is incredibly powerful — for debugging, compliance, or even simulating “what-if” scenarios. It changes how you think about software, because you no longer lose information when updating state.

Have you and your team encountered any challenges with full-stack event sourcing?
Yes, one of the main challenges is the increased complexity — especially when introducing it to the frontend. Replacing something like Redux with an event-sourced approach requires careful modeling and a good persistence strategy, like IndexedDB. On the backend, challenges often come from handling large event stores efficiently and designing projections. But overcoming these challenges pays off in scalability, flexibility, and long-term maintainability.

Why should we not miss your presentation on October 24th?
Because I’ll be showing a practical demo of full-stack event sourcing — not just theory. You’ll see how to apply event sourcing both in the client (with a replacement for Redux backed by IndexedDB) and in the backend API. We’ll also explore Event Modeling, which makes event-driven design more approachable and collaborative. If you’re interested in scaling frontend and backend together with a consistent event-driven architecture, this session will give you both the big picture and concrete takeaways you can use right away.