Oskar Dudycz

Pragmatic about programming

Production-Grade Event Sourcing Workshop - Modelling, DevOps, Process

2024-02-04 oskar dudyczEvent Sourcing

cover

Putting the career bets is not easy; I made boring and pragmatic choices for most of my career. They took me far. Yet, I always felt that something was missing and that my systems could be delivered and operated better. I tried many things; I even finished my post-graduate studies around project management.

All of that helped me make an impact, but the most significant A-ha moment for me was Event Sourcing. Why?

It helps to create the synergy between business and development. Thanks to that, we can get the fastest feedback loop, streamline development and operate with more insights and data correlation. We’re investing in the quality of the information in our system without losing much.

Event sourcing is already battle-tested by both big and small companies. They see the advantages it brings, e.g. business focus and keeping all information about the business process. It can also be a great input to analytics, providing increased diagnostics and tracing. Nowadays, that’s essential for running a system on the scale.

There are already decent materials teaching how to start the journey with Event Sourcing. Hell, I wrote over 100 of them on this blog. Yet it’s not easy to get certainty that our design will work on production. Even when we get there, it’s worth revisiting lessons learned and discovering what we can improve in preparing for the upcoming challenges.

That’s why I’m explaining the nuances, strategies, tips, and tricks of having your event-sourced system well-architected. We need more of that!

I want to invite you to my biggest initiative so far!

A three-day workshop on Production-Grade Event Sourcing: Modelling, DevOps, Process

The goal of this workshop is to strengthen all of the critical aspects of running event-sourced on production:

  • modelling (like keeping streams short, managing consistency and efficiently handling business logic, best practices and anti-patterns),
  • managing schema evolution, so events versioning,
  • advanced projections design and resiliency, so how to get the best from events to efficiently get read models and insights from them,
  • DevOps techniques (like traceability, blue-green projection rebuilt, archiving old data),
  • handling distributed processes and integrating with other systems,
  • putting event sourcing as a vital part of the whole architecture (so how to integrate it with non-event-sourced modules, defining private and public schema).

The workshop will happen May 27-29, 2024, as part of Domain Driven Design Europe. Do you know how beautiful Amsterdam is at that time of the year? You better check that!

You can sign up through the workshop page.

What will you learn

After the workshop, you’ll understand and practice techniques that will allow you to run your Event-Sourcing system on production. All the exercises will be backed by the versatile knowledge I gained through my projects and working with my clients.

I’ll share my experience building systems like Marten and EventStoreDB and working as an architect and consultant in many Event Sourcing projects.

We’ll start with the project of the system that looks fine as the first production deployment. Through group exercises, a mixture of modelling and practical coding exercises, we’ll analyse potential issues step by step. We’ll learn how to refactor it step by step without breaking it. That will allow us to fix the boundaries, consistency guarantees, and resiliency. We’ll practice both adding new capabilities and changing existing ones. We’ll practice schema evolution and DevOps practices like projection rebuilds. We’ll end with a more robust and prepared-for-the-next-challenges system.

Prerequisites

The workshop is designed for people who already have experience with Event Sourcing. Especially for those who would like to assess the production-readiness of their design or already deployed system. We won’t start from basics but assume:

  • experience in how Event Sourcing works (storing events, building state from them),
  • knowledge of how to model business logic and projections/read models,
  • Understand that event sourcing is not event streaming and why streaming solutions like Kafka and Pulsar should not be used as event stores.

I assume you know modelling techniques like EventStorming, C4 and modularity concepts (microservices, monolith, CQRS, etc.). And that you were already building and designing web applications. You don’t need to be an expert in that, but the more you know the easier it will be.

Most of the exercises will be focused on general understanding and will not be technology-specific, but practical will require knowledge of one of the languages: C#, Java, or TypeScript. We’ll use Marten and EventStoreDB as event stores examples.

What if you don’t have Event Sourcing experience yet?

I’ve got you covered! Check my self-paced kit.

See the playlist with my talks:

Of course, that’s not the full experience of doing a workshop, but it can be a good starting point.

If you need more than that and want full coverage with all nuances of the private workshop, check the training page. Feel invited to contact me via email. I’m happy to help you via consultancy or paid mentoring!

If you’re not persuaded enough, check recommendations from my previous clients on my LinkedIn profile..

Here are some of them:

reference 1

reference 2

reference 3

Again, feel invited to sign up for the workshop.. And contact me if you have any questions.

See you in Amsterdam!

Cheers.

Oskar

p.s. Ukraine is still under brutal Russian invasion. A lot of Ukrainian people are hurt, without shelter and need help. You can help in various ways, for instance, directly helping refugees, spreading awareness, putting pressure on your local government or companies. You can also support Ukraine by donating e.g. to Red Cross, Ukraine humanitarian organisation or donate Ambulances for Ukraine.

👋 If you found this article helpful and want to get notification about the next one, subscribe to Architecture Weekly.

✉️ Join over 11500 subscribers, get the best resources to boost your skills, and stay updated with Software Architecture trends!

Loading...
Event-Driven by Oskar Dudycz

cover

Through my window, I see the result of good plans but poor execution. Opposite my flat, there is a partially completed construction place. Buildings were supposed to be eye-catching Mediterranean style apartments. Delivery date? Two years ago. Actual? More and more unknown.

Some time ago, I heard that using Event Sourcing makes creating Event-Driven Architecture easier. The arguments were correct, that if we’re already publishing events to trigger business workflows, then at some point, we may want to also store events to not lose information. Agreed. However, I also heard that keeping the state as events will simplify things. We’ll have a source of truth with a record of the system behaviour. This will allow, e.g. to confront the results of the operations with the recorded state. I’d agree with that, with one distinction. It’s easier as long as you already know Event Sourcing.

Many people in the DDD community claim that the essential is to properly break down the system into autonomous parts called bounded contexts. Once we have it, the rest is secondary and will sort itself out. For sure.

Many seasoned programmers speak similarly about new technologies. They claim that they can translate past experience into new technologies. That’s true that by analogy, they can catch the big picture quicker. But isn’t it a bold assumption to say that Win.Forms specialist will learn Angular quickly?

The end result may differ a lot from the initial ideas. I saw the plan of those buildings next to me. Now I can see the effects of the execution. Or actually, the lack.

I believe that we should carefully acknowledge not only the point of view of our authorities but also their seating point. If we want to find out how to form a wall, do we ask an architect or a foreman? An architect may know the theory, but the practice is what we’re looking for. On the other hand, if you want to know where to put the wall, you prefer the architect to do measurements. At least if you don’t want to have the roof falling to your head.

After I had torn a ligament in my knee, I went to two qualified orthopedists. One said I should have surgery and do a reconstruction. The second stated that there is no need for that; rehabilitation should be enough. Guess which one had a specialization in surgery and which in rehabilitation?

People usually give us advice from the point where they’re currently standing. They are entitled to a biased view. An architect who rarely does programming will tend to downplay the value of implementation and tactical patterns. Midlevel developers will focus on technicalities instead of the global system impact. The team manager or consultant will emphasize the importance of soft skills (or esoteric techniques known only to them).

The truth is that we need all of them. The excellent plan will fall on the bad execution. The best execution for the wrong case will be just a waste of time. We should carefully evaluate the advice considering what we need and what an expert can give us.

Therefore, when we’re reading an article, watching a talk, let’s also pay attention to the place where the person is standing. The perspective from there may be much different from where we are right now. That can be good, as it may push us in the right direction. But it may also be misleading, as we accidentally take biases of this person without understanding the tradeoffs. Personally, I prefer to follow not only people from pedestal but also those that are closer to my position. A bit further in the journey, but not too far. That helps me to calibrate my view as those people are more relative to my daily struggles.

Polish historical leader Józef Piłsudzki reportedly used to say: “Right is like an ass, everyone has its own”.

Cheers!

Oskar