Martin Dilger, founder and CEO of Nebuilt GmbH, speaks with host Giovanni Asproni about event sourcing — a software architecture pattern in which, rather than storing just the current state of your data, you store a sequence of events that represents every change that has ever happened in the system. This episode starts by introducing the vocabulary around event sourcing, highlighting its relationship with event modeling, event streaming, and event storming. Martin describes some of the pros and cons of the approach, including which systems it is most suitable for. The conversation ends with guidance how to get started with event sourcing, for both greenfield and legacy systems.
Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Related Episodes
Related Resources
Transcript
Transcript brought to you by IEEE Software magazine.
This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number and URL.
Giovanni Asproni 00:00:18 Welcome to Software Engineering Radio. I’m your host, Giovanni Asproni, and today I will be discussing event sourcing with Martin Dilger. Martin is the founder and CEO of Nebuilt GmbH, a consultancy focused on helping software teams design and implement event-driven systems using event modeling and event sourcing. He’s also the author of the book Understanding Event Sourcing and a frequent conference speaker. Finally, he’s a co-host with Adam Dymitruk of the Event Modeling and Event Sourcing podcast. Martin, welcome to Software Engineering Radio. Is there anything I missed you’d like to add?
Martin Dilger 00:00:51 Hello, Giovanni. Very glad to be here. Thanks for the invitation. No, that was a very kind introduction. Thank you.
Giovanni Asproni 00:00:57 Okay, so I want to mention an episode related to this one that is Episode 539 with Adam Dymitruk that was on Event Modeling. So, in this one we’ll specifically focus on event sourcing. We’ll mention of course the relationship between the two because it’s important. Yeah. But we’ll be mostly about event sourcing. So, for the listeners that want to know more about event modeling there’s the other episode they can look at. And now, let’s start with a simple question for you, Martin, that is, what is event sourcing in a few words?
Martin Dilger 00:01:27 You really think that is a simple question? Many people struggle with this. So, in essence, many people start to look at it from a technical perspective. So, if you wanted to look at it from a technical perspective, because we also have a technical audience, it’s just a different way to store information and to process information. So, if you look at a typical Crud architecture, what we’re doing is we are just storing structured objects without any history. And event sourcing turns this around a little bit and we just, we start a whole history of things that happen in our system in the form of events. That’s the only thing that event sourcing brings in. And this has some quite interesting effects on information processing and how you structure your whole system.
Giovanni Asproni 00:02:04 Okay. Can you give me quickly just a small example maybe of a system you worked on about this? So just to give the audience an idea of what may look like a system like this, I mean.
Martin Dilger 00:02:14 Yeah, of course. So, for example, I’m currently working on a system that processes law information: so it’s in the law space, so working a lot together with law agents. And what we do there is if you open a new case, instead of storing the typical case information in a table that is called cases, which is star, a new event, which is called case created for example. And whenever there is a new case in the system, there is a new event that is stored, case created, and then you have a complete history of all those cases and you can just look it up, when was this case created, who created this case? All the information is stored.
Giovanni Asproni 00:02:44 Thank you. And the terminology, terminology around events in software can be really, really confusing. So have the relationships, if any, between event sourcing, event streaming, event storming, event driven, there is a lot ofÖ
Martin Dilger 00:02:57 You forgot about event modeling. That of course is also something.
Giovanni Asproni 00:02:59 Event modeling of course. Yes, youíre right.
Martin Dilger 00:03:01 Yeah. The problem is actually, I don’t like the term at all because it’s so bloated. Whenever you say event, you can ask two developers, and you will get three answers at least. So many people have a very different understanding. And also, as you mentioned, there is event streaming, there’s event storming, all those different terminologies all around events and they mean very, very different things. So, first of all, when I say event, what I mean with this is not a technical term. An event is just something that happened in the system. It’s a fact that happened in the system. It’s not a technical term at all. I’m really looking at information systems and I typically refer to software systems as information systems. I really look at them from a business perspective. So, an event is just something that happened in the system from a business perspective, any businessperson can understand this immediately. Something that happened in the system that’s all, all at an event is,
Giovanni Asproni 00:03:50 And now a bit of with event modeling, because even sourcing and modeling, as we said, they are kind of strongly related. So event modeling in a few words, what is that?
Martin Dilger 00:04:00 Event modeling is the starting point of any information system. So many of the listeners most probably are familiar with event storming, which is very similar to event modeling. Event modeling has just some specialties that are different to event storming, but in essence it’s a collaborative modeling technique. And the idea of event storming and also event modeling is you bring people together very early in the process, very early in the project also, and they start to discuss things. You start to discuss those problems because one thing I realized a few years ago and that changed my whole career was that the problems we are facing in most of our systems, in most projects, and I’ve been in the industry for over 20 years and all those projects I was involved with, they faced the same problems. It was always communication, it was never technology, it was always communication.
Martin Dilger 00:04:45 When you bring people together very early in the project and you make them talk to each other and really talk about the problems, many of those problems, they simply seem to fade away because when you make people talk to each other and they really find this common terminology, this common language, everything seems to work suddenly and this is almost magical and event modeling, event storming and all those collaborative modeling techniques, they do just that. Basically, they enforce good communication in the project, especially together with event sourcing. That’s just a great combination to build information systems.
Giovanni Asproni 00:05:14 Okay. And so what is the relationship with event sourcing? We come from what you said, event modeling seems to be some level of, I donít know, in between requirements and design, maybe high-level design, not technical design of the system.
Martin Dilger 00:05:26 Exactly. So, what you do basically with event modeling is you just describe an information system from beginning to end. The big difference to event storming is in event modeling, you do it along one single timeline. So, it’s like you are telling a story, you’re finding the story of a system together with engineering, together with the business experts and it’s always readable for left to right. And that’s the amazing thing because everybody knows how to read from left to right. So, in an event model, you can start on the left side and if you want to know how a certain business process works, you can just go from left to right step by step because, because everything in the event model is laid down step by step and you can understand what happens in the system step by step. Basically, it’s like a prototype. You can go through it like a prototype, and you see exactly screen by screen what is going on in the system.
Martin Dilger 00:06:08 And if you look at that, it’s a perfect blueprint to an event-driven system and also to an event source system. So especially when you work with event modeling, there’s a very easy mapping between your event model and the event source system. It’s so simple that you can even use it to generate code. This is what I’m doing a lot. I’m generating a lot of code, so I’m sitting together with clients, we model their processes, try to understand their problems, and when we did that, we used the event model directly to generate code from this. And this really, really interesting, really interesting way to work.
Giovanni Asproni 00:06:39 One thing that you wrote in your book, you said that one of the most interesting things about event sourcing is that it’s natural alignment with human thinking. What do you mean with that?
Martin Dilger 00:06:48 When you develop systems without event sourcing, so what happens when you get a problem as a typical developer, you sit down and the first thing a developer thinks of is, okay, what is the tables that I need? Oh, let’s take a simple example. I need to build a user registration. Almost every developer will immediately think of a user and of a user’s table and an address table and the typical structural things you see in the system, what they don’t do is they don’t talk about the processes behind that, but when you go to business, they never think about tables, they never think about users. And those structured classes you have in your system, they think in processes. And when you use event modeling and also event sourcing, you start to think in processes. Because when you think in events it’s always, oh, this happened and then this happened and then the user was registered and then this notification was sent, very natural. Basically, you can tell the story in natural language and this can directly be mapped to an event source system because that’s exactly what happens there.
Giovanni Asproni 00:07:40 Going to event sourcing more detail now. So of course, there are several parts it now we’ll discuss them all when we talk about internal external events, event stores, projections and other things.
Martin Dilger 00:07:51 Oh yeah, all those technicalities.
Giovanni Asproni 00:07:52 Yes, we like to talk about those. But I’d like to start with the core patterns because again, reading your book followed by Adam Dymitruk, he wrote, event sourcing is not only revolutionary but also responsible with just two core patterns. It was remarkably simple. So, what are these two core patterns?
Martin Dilger 00:08:11 Actually I refer to them as four patterns. Adam uses the question two patterns, but I use four patterns because for me that is simpler to explain. So, in essence that’s what you do when you use event modeling. You break the system down into tiny little steps, we call them slices. So basically, what you have in the end is a slice-based architecture, but you break them down into slices and they’re basically just two types of slices. The first slice type is state change slice, state change just means how does information get into the system. There are just two ways to get information into the system. Typically, it’s a screen, you have a screen, a user clicks on, a button on the screen, fires a command into the system. And if everything goes well, there’s a new event in the system, a new information that is stored in the system, that’s a state change slice, basically just getting information into the system.
Martin Dilger 00:08:57 And the second slice type is a state fuse slice. So you use these events which are already available in the system and you provide it for the next screen. You provide them for the next background process. That’s all information getting into the system, information getting out of the system. And if you break the system down into those patterns, suddenly it becomes very simple because every system in the world, no matter how big it is, no matter how complicated it is, can be broken down into state changes and state views. And if you put them together like Lego bricks, that’s basically your system. And breaking those systems down into those tiny little steps makes it really easy to reason about even the most complex business processes because most problems, if you break them down, they become really simple and it’s really amazing. And that’s one of my biggest learnings. Almost everything we do in software development isn’t complex. Most of the things we do is rather simple. If you just break it down, they just look so complicated. If you look at those big problems and if you have stories in your estimations that last for a thousand person days, well that looks intimidating and that looks really problematic. But if you break it down suddenly it’s just 1000 tiny steps in this process. And every tiny step is very simple in and of itself.
Giovanni Asproni 00:10:04 Okay. And now let’s go about the other parts. So again, maybe you can start telling us if all the technicalities here. So talking about the events, the type of events, the event store. So tell us, well maybe a story these parts and connect them together, how connecting them together so we understand now is event searching is actually made here, it’s composed of.
Martin Dilger 00:10:24 Yeah, maybe we can put in a tiny little bit of event modeling here before we dive into event sourcing because it makes it easier to understand where this leads. So if you do an event modeling workshop, it follows seven steps. So in the end what we try to do is we try to map out the system step by step. And the first thing we do typically is what’s called the brainstorming. There we gather all the people who are involved in the project. So, in the first step brainstorming, many people can participate in the workshop, it can be 30 people. I had event modeling workshops with 30 people, and I do this a lot. I do a lot of those workshops for companies to help them get into event modeling and also into event sourcing. And the first part of the workshop is always brainstorming.
Martin Dilger 00:11:01 That means you gather all the events, just like putting sticky notes on a giant whiteboard. And this can be a hundred, this can be 500 events depending on how many people participate. But the interesting thing is what we are already doing here is we are shaping the ubiquitous language and every developer who’s listening now will immediately make the reference to the main driven design. And this is exactly what we are doing there. It’s always difficult to find the ubiquitous language. Ubiquitous language is basically the one language we are having in the project that everybody understands. Engineers, businesspeople, security, everybody talks the same language. When I say customer, everybody knows what that means. In most projects, that is absolutely not the case. We have different terms for the same thing. You say one thing and everybody understands something different, one of the biggest problems we have in our project.
Martin Dilger 00:11:46 But when you bring those people together and you just make them put those terms, those events on a board, suddenly those people start to discuss sometimes for the first time in their life, what is the right naming for this? Can we find a common terminology for this? And this is where we already start to shape the ubiquitous language. The next thing that we do is we try to bring them in an order. This is where we form the story of the whole system. I call this storyboarding. It’s just you take this whole cloud of events and to try to bring them in an order. This is where we try to find the story of the system, what happens one event after the other. And just looking at the result of the storyboarding is very interesting because you can already see first how big is the system, and second, what happens one step after the other.
Martin Dilger 00:12:28 And this already gives us an indication, okay, what is the first thing that we need to tackle? What is the second thing that we need to tackle? The story really becomes visible only after that, and this can be after 30 minutes. So, storyboarding and the brainstorm, this can be just 30 minutes and we already start to map out what happens in the system. And the next thing that we do in event modeling is we draw screens. Screens are also very important part, and this is a key differentiator to event storming. Also, we heavily draw screens and screens is really important because this allows everybody in the project to understand what we are discussing. So, if you leave out those screens, and I see this a lot in workshops, people are confused because businesspeople, they are not used to thinking events. And many, many engineers are also not used to thinking events. Thinking in events, it’s a different thing. If you’ve been in the crowd world and you’ve developed crowd-based systems for 20 years and you learned from scratch, building crowd-based systems thinking in events is all about natural to you. And many people struggle with this, but if you bring in screens to the story, suddenly everything makes sense. That’s really you have something visual and you can map the screen to the events and that seems to work for everybody. And I see this very, very often.
Giovanni Asproni 00:13:36 Well, it’s really almost a visual prototype of what the system may look like. Even if it is not the final design or anything, it’s just about maybe the flaws or the way it works but gives people an anchor in their heads on how the system works I guess and helps.
Martin Dilger 00:13:51 Okay. And many people try to skip this because they think, oh, it’s so time intense to draw those screens. I don’t want to do this. I have a very simple rule. If it takes you more than two minutes to draw a screen, you are absolutely doing it wrong. Two minutes is the absolute maximum you must take to draw a screen. So in essence, if you do event modeling, drawing ugly screens is a key skill you need to master. My screens are the worst, they’re super ugly and I’m really proud of that. So, I can draw very good screens, very ugly, but very efficient. The key thing why we need those screens is you need to understand what does the user see? Is there a button, is there an input field? What is displayed? It doesn’t matter if it’s a radio button or a checkbox or something like that.
Martin Dilger 00:14:29 UX, people hate this, they hate this in the beginning because they want to discuss of course the pixel perfect screen designs. But this is absolutely not what this is about. So it’s really like, okay, let’s break this down step by step. And what we see there already is, we see the slices slowly forming slices. Are the building blocks in the system? What are the screens? What are the events that we have step by step. They’re already, you can see how the event driven and event source system slowly forms. And the next thing that we do then is when we have the screens and the events, we just define what are the commands and what are the read models. Now we come a little bit more into the terminology that goes in the direction of event sourcing. So, commands and read models are basically just two important elements.
Martin Dilger 00:15:07 What is the command? The command is basically just an instruction to the system. You want the system to do something. So, register user, for example, could be a command that you send to the system, and you want this user to be registered. You don’t know if it works. You don’t know what business rules are behind it. You just sent this command to the system. I want this user to be registered. If everything goes well, you have a new event in the system. But of course, there’s a lot of validation going on because typically every command that we send to the system is backed by a whole lot of business rules. But if everything goes well, the successful command execution means there’s a new event in the system. But then if we progress in the story, so in the event model, we go from left to right, there is a next screen that comes, and this next screen shows a list of registered users.
Martin Dilger 00:15:48 Now you need to show, well where does this list of users come from? And there you just use the information that is already available in the system. It’s the events and you project them to the screen. How do you do a projection? That’s a read model, an event model. We call this a read model. It’s just a green sticky note that shows you this is the information that is displayed on the screen and these are the events that provide this information. So, what we are doing with event modeling is we call this information completeness. So, for every step in the system, you need to be very sure where does this information come from. So, you cannot make any wrong assumptions. What is one of the biggest problems you face in most projects, it’s wrong assumptions. You just assume information to be available. And then later when you go into the implementation, then you realize, and that’s very late in the project, then you realize, oh, some of our assumptions they weren’t right.
Martin Dilger 00:16:36 It’s a problem because you already allocated the budget, you already had the project planned, you already planned your sprints, you’re ready to go into coding. But now you realize, well, we cannot do this, and this is where it gets really, really expensive because now you need to do the replanning. All the things you did before was basically just a waste of time. Event modeling turns this around. We ask those questions in the very beginning of the project very early. So, if there is a gap in our requirements and email is not available, information is not available. We know from the beginning because you see it in the event model, you cannot map the event model if the information is not available. So, for every step, basically we break it down and we know is the information available or not. And to build those screens, for example, you need to read model. And back to the terminology of event sourcing, that’s basically called a projection. You use these events in the system, and you simply project them to the information you need to display discrete.
Giovanni Asproni 00:17:26 In your book you say that using event sourcing, we are adding the dimension of time to our system. So, the system records the facts that happen along the timeline, which you said with events, at least things that happen. You said this dimension gets lost when data is flattened to a relational database schema. Tell us more about that.
Martin Dilger 00:17:43 Let’s go back to this example of the user registration. So, what you have typically in a traditional architecture, you just have a table with user information, but you have absolutely no history. How this information got in there, was this user registered? Was this registered by an automatic process? Was this done manually? Was this done by an administrator? How often was this user changed? All this information is lost. Typically, if you need to know what happened to this user, if you are lucky, you can get into the logs or into your temporal tables and find out what happened to this user. But from an architectural perspective, this information gets flattened, and it’s lost. And event sourcing is the exact opposite of that. The timeline, the information, how you got to a certain point in the system, it’s an essential part of the architecture. So, you have everything recorded, every decision you made in the system step by step and basically since the beginning of your system. So, I have clients who work with event sourcing for 10 and more years. They have tons and tons of information in their databases. Every decision ever made in the last 10 years is recorded as a fact, as an event in the system. That’s informational gold that they have there. So, everything is recorded and basically you throw this away intentionally if you just study information and not the history behind it. And I will never understand why you would do this intentionally. For me, this makes no sense, not at all.
Giovanni Asproni 00:18:59 I can say in relation database; you can store some of that information. Surely when somebody registers and you say you can put this, you know it’s been automated or somebody else. But if there are changes during time on this information that that becomes a bit more difficult. Sometimes there is some versioning of stuff or versioning of tables, but that becomes a bit more difficult in the relational database to keep track of.
Martin Dilger 00:19:22 Oftentimes what you do is of course companies need this information. So, what they do is they need to work around this. So, you work with temporal tables which store information along a timeline, but it’s not really usable. You cannot work with this information, it’s just there. But typically, when I ask a client, how often did you use your temporal tables, the answer is never because it doesn’t work. Same question, how often did you use your backup? Well never because it doesn’t work well, why are you doing then? It’s always the same thing.
Giovanni Asproni 00:19:49 Yeah, it’s definitely more difficult to keep that information in a reasonable manner. But also, another thing then, well, a question after this one, because we say we store every single decision and forever, you know, 10 years or more. But then how do you manage this information if it starts to become big? If you start to have a lot of information, a lot of data in your databases, what do you do? Is there any form of archiving of events, deletion of old events? I donít know.
Martin Dilger 00:20:16 Yeah, so of course I often discuss with clients who want to learn about event sourcing, who want to understand event sourcing. And those are the first questions that typically come, wait a second, if we start every decision, this will get crazy because in a crowd-based system we simply override the information and then it’s gone. And so, we have very clear picture of how big this data is that we store. In event sourcing that’s basically unlimited. How should we deal with that? But first of all, if you store events, it doesn’t get so big typically if you do it right, so it’s not like you’re storing millions and millions of events that you need to process to get to a certain state. That’s typically not what happens. So oftentimes what you do is you store information per process and the process itself isn’t infinitely large. Your processes are typically very small and contained. So, what you have is you have streams of events and those streams of events, they’re typically very small. So, if you want to know what happened to this,
Giovanni Asproni 00:21:11 A question, when we say process, we mean what a software process running or a business process?
Martin Dilger 00:21:16 I’m specifically talking about the business process. So, you really look at the business processes and typically you have the history of your customer, customer was registered and a few more things that happened to this customer. That’s one stream of events that you store in your database or that you store in your event store. But the history of this customer isn’t infinitely large. Maybe it’s 10, 15, 20, 30 events or maybe it’s a hundred events, it doesn’t really matter. All those processes there typically very small and typically it doesn’t happen that you have to process millions of events to get to a certain state. If you do this, typically there’s a problem in the modeling or in how you structure your information, it shouldn’t be the case.
Giovanni Asproni 00:21:53 And so how many of these streams a typical event source systems? So, there is several streams.
Martin Dilger 00:22:00 It depends on the number of your business processes in the system. So, it doesn’t really matter how many streams you have. So typically, you just define those streams alongside your business processes. So, if there is a customer registration that is a dedicated stream, if there is a card system that you have in your e-commerce system that might be a dedicated stream, a card session might be a dedicated stream. So, it’s really you design your processes. If you have events that belong together to a business process that typically also belongs to a stream and then there comes a few other terminologies. So typically, then you talk about aggregates or if you talk about newer concepts in event sourcing, that’s DCB, but we can talk about this a little bit later.
Giovanni Asproni 00:22:39 And also in these streams. So, if you have several streams, can these streams be dependent on each other? Are there any dependencies there that you would need to manage?
Martin Dilger 00:22:47 It can, yes, of course. So it can, so typically what you try to do is you try to contain those streams. So, what you try to do is you try to keep those streams consistent. Within a stream you only want to have consistent data, same as you try to have consistent data in your traditional architectures. It’s the same idea. And if you build an event source system, what you nowadays have typically is you have an aggregate, and this aggregate is basically a protection for your stream. So if you send a command to your system, the first thing that happens typically is something in your system just checks, can I execute this command? Is this valid? If I execute this command, will my system be in a consistent state? And the thing that does this typically is the aggregate. It just sits basically on your stream and checks; can I execute this command or not? And typically, what you try to do is you try to keep those streams self-contained as much as possible. But of course, there can be dependencies between streams, but you try to keep them as consistent as possible in themselves
Giovanni Asproni 00:23:41 When there are dependencies, how do you manage those? I’m thinking from the perspective of if you want to rebuild the state of the system at certain point in time, if you have these dependencies, how do you manage these different dependencies across streams to have a consistent state of your overall system?
Martin Dilger 00:23:56 That’s a very good question and this is where many teams really struggle because oftentimes though, what teams come up with when they reach that status, the saga pattern, the saga pattern is basically how to define long running processes and keep the system consistent even if it’s across streams or even across different systems. I never use that in my systems, I don’t need this. What we do in event modeling basically is we call these automations, it’s basically just another process step that is responsible to use the information in one stream and send it to another stream that’s basically, you could call it the tiny little saga, but typically I neither use the term saga pattern. Now do I use this concept in my systems? I don’t need it, but there’s a small piece of automation or a small piece of software that just uses information from one stream and knows how to transform this information to another stream. And that’s how you manage those dependencies typically.
Giovanni Asproni 00:24:47 Okay. In terms of performances, because surely you have this question all the time, are there any implications in terms of latency response time, memory, any performance implications on these systems?
Martin Dilger 00:24:59 So that’s of course one of the biggest questions that comes up because many people have a very wrong understanding what event sourcing actually means. So, if I talk to developers what they think is, well, if I want to know what my customer looks like, every time I want to know this, I go to my event store and I read all the events of this customer basically every time I need this information. That is typically not what happens. So, what you have in event sourcing, and I use this a lot, is just persistent projections. So at runtime it behaves exactly like every other traditional architecture as well. So, what happens, basically whenever there is a new event, this gets persisted to a persistent projection. And this can be a relational table for example. So, at runtime what you do is you read your customer’s table, it’s still your customer’s table, but it’s not your source of truth, the customer’s table, but it’s just a projection of the events of this customer. And whenever you want to change this or you need new information from this customer, you can just build a new projection or two new projections of this. You have very, very flexible in how you work with your informations.
Giovanni Asproni 00:25:56 Okay, so if I’m understanding correctly, you have events that you store somewhere and then there are facts, things that happen to data, but then every time an event happens we can update say a table in a relation database, which is basically the most recent view of the particular dataset is a customer as you said.
Martin Dilger 00:26:15 Exactly, exactly as you said. This can be like a snapshot.
Giovanni Asproni 00:26:17 Okay. And so, if I want to see that at the past time, what I need to do is rebuild that view, but up to a point. So not up to the most recent event, but maybe an event, I donít know, 10 days ago because if I’m interested today in the past I do that.
Martin Dilger 00:26:32 Yes. For example, if you want to do that, if you need to, and I do this a lot for bug fixing for example, that’s exactly how you do bug fixing in event sourcing. If you want to know what the system looks at a certain point in time, you can just build a new projection out of it, use exactly the events to reproduce this button. You know exactly what the stage was when the customer clicked this button and then you can just look, okay, the user clicked this button, the system was in that state. Well that’s clear, this is the problem. Very interesting way to work. And why is this so powerful? If you define everything in a table, in a traditional architecture, you have just your customer’s table and all your use cases, they’re using this customer’s table that creates a ton of coupling.
Martin Dilger 00:27:08 And coupling is one of the biggest problems we face in our architectures because now if you change one of those use cases, you have to retest all the other use cases because they all depend on the same tables, they all depend on the same information. In event sourcing, this completely goes away because what we are doing is we define one projection for each of those use cases. Every use case has its own customer’s table with just the information that it needs. It doesn’t need everything in this table typically it’s just a tiny fraction of this information. So you have not one customer table, you have many smaller customer tables specific for those use cases. And this gets rid of all those coupling problems. And it’s an amazing way to define systems.
Giovanni Asproni 00:27:47 And in terms of evolution of events, because I can imagine that over time you want to change some information, maybe as example associated to a customer. Maybe you want to change the format of the address or add some more information. Basically, you have a situation where the events change in terms of what the information they carry. So how do you manage this evolution?
Martin Dilger 00:28:09 Yes, there are different ways how to deal with it. So, I always approach this in the same order. So, the first thing I typically check is if I need to change an event because maybe there is a new field. Is this really just a structural change to the event or is this maybe a new event? So, for example, if we need to add a field to the customer address, maybe this is like a postal code added event, can I just add a new event to the system that basically brings this information to the existing event? So, I try to not change events if I don’t have to. So that’s always the first thing I try. It’s much easier to introduce new events as long as they have real business meaning. So, I don’t introduce new events just for, to introduce new events they need to be relevant to the business.
Martin Dilger 00:28:48 But if that is the case, that’s my first choice always. But sometimes this is not the case. So very, very stupid example, there is a typo in a field, in an event, do you want to keep that, or do you want to change that? So sometimes you just need to make structural changes to an event. And if that is the case, what you typically do is you just introduce a new version of this event. So, events are typically versioned. So that will be then just a customer registered v2, a second version of this event. And then you can slowly and gradually adjust all the projections that depend on this event. And then at some point in time you just work with this version two of the events. And if you need to process those older versions of an event, typically what you have is the concept is called an up caster. And that you basically take this first version of the event and there is a small piece of infrastructure that knows how to transform this version one into a version two. So, your system only from this point on has to work with the version two of the event. That’s typically how you deal with those things.
Giovanni Asproni 00:29:43 Is there a risk that over time you write a lot of software in your system to do lots of up casters if you like?
Martin Dilger 00:29:49 Yeah, I mean of course that can happen, but in reality, that is typically not the case. So, your business process, they don’t change over time and typically business process, they’re very stable. And since what we are modeling and what we are discussing is the business process, they tend to be really, really stable. It’s very different if you look at it from a technical perspective because the technicalities in the project they change very quickly, but the processes themselves, they’re typically very stable. So yes, in theory that could happen in practice that is not what I see.
Giovanni Asproni 00:30:18 Okay, so in practice is less of a problem than what it looks like?
Martin Dilger 00:30:23 Yes, basically.
Giovanni Asproni 00:30:24 Yeah, I can understand this because if you establish the ubiquitous language at the beginning, basically, if I understand correctly, you’re focusing a lot on the business. So, the business processes actually drive the shape of the data and information. Since those processes change slowly, chances for this data to change are actually not that big at the end of the day. Instead, if we go the other way around, if we model the information without considering the business processes from the beginning, we may end up in a situation where we keep changing those much more frequently. Am I understanding correctly?
Martin Dilger 00:30:57 Yes, absolutely. That’s exactly the point. And what is also the point is those events, they are really happening at very specific points in the process. So typically, if you refactor an existing database, often this has effects all over the place in the system typically. But if it just changes one event, the effect is very, very small and very contained. So even if you change one event, it typically doesn’t affect all the other places in the system. So, changes in the system are very contained in very small areas. So, it’s typically not a big problem.
Giovanni Asproni 00:31:25 Okay. And let’s talk a bit about adoption. Yeah. So, the first question I have about this is what
Martin Dilger 00:31:31 Difficult topic.
Giovanni Asproni 00:31:32 Why do you think it is difficult? Is adoption something that is complicated for teams in general or?
Martin Dilger 00:31:41 Yes. So, first of all, event sourcing. I don’t know why, but most companies are terrified to death from event sourcing. They’re really afraid of applying it, of doing it. And I don’t really know why that is. So, I could never find out why this is the case. But whenever I mentioned event sourcing to a company, they immediately go, no, no, no, no, we tried that once we miserably failed and we will never ever do it again. Well, that’s not really a problem of event sourcing. That’s just either you applied it wrong or maybe there was a problem in the modeling. So typically, it’s not, whenever we have this discussion and we dig a little bit deeper, it’s not a problem of event sourcing, it’s typically a problem. Oh, you applied it wrong. Let me give you a very prominent example. Something I see very, very often. Customers tell me, well, we tried event sourcing, and it failed. And typically of course I ask, okay, tell me a little bit what happened. Yeah, well we had Kafka. Kafka was our event store, and this is the whole story. I don’t need to hear anything else. Kafka is neither an event store nor is it suitable for event sourcing. It’s a completely different thing. Of course it failed, but that’s not a problem of event sourcing, it’s just you try to do something with a tool completely unsuitable for it.
Giovanni Asproni 00:32:49 Just to be clear, for our listeners that have never seen or heard of Kafka, what is Kafka quickly?
Martin Dilger 00:32:55 Kafka is basically, it’s an event streaming platform. So that’s the crucial difference between event sourcing and event streaming. If you want to think about it, Kafka is basically, it’s like the highway between your systems. So, what Kafka is perfect for, and it works very, very good at it can transport information from A to B in light speed super, super fast. That’s what Kafka is for. It’s your highway between systems. But if you want to know what happens within your system, if you want to record the decisions and the history of your information, that’s what we talk about event sourcing. But that’s a completely different story than the highway.
Giovanni Asproni 00:33:28 Can we say that Kafka is more about implement some kind of communication protocol, not a storage of events?
Martin Dilger 00:33:34 Basically, yes. So, you put information on the wire in one system and it comes out in the other system and in between there’s only two milliseconds because Kafka is super, super fast. But it’s not suitable for event sourcing. Absolutely not. So please, please don’t use Kafka as an event store.
Giovanni Asproni 00:33:50 Yeah. It’s one of the things you had the same before. Maybe people get confused between event sourcing it, event streaming, what they are all the time. All the time. And now that you are it. So, I said Kafka was the wrong technology, but in general, what kind of systems is event sourcing more suitable for?
Martin Dilger 00:34:05 That’s a very interesting question and my opinion here is a little bit contrary to what most people in the industry are saying and listen in the industry, what people are saying, typically they say the default is Crud and only if you have a very specific use case, you should use event sourcing. So, event sourcing is not for everything. Only use it if you have a very specific use case. For example, you work in a regulated industry, you have a lot of audits that you need to make, stuff like that. Then you use event sourcing. My opinion is a completely different one. I say event sourcing is always the default because it’s a simpler way to build system and only if there is a very, very specific reason I would fall back to building a Crud based system. So, the only reason I would build a Crud based system is if I clearly have only a Crud based application, which is basically just a form with a lot of information that I need to store. But even then, the problem is those forms typically sooner or later also turn into real applications, into real business processes. And then you would also benefit there from event sourcing. So, if you ask me, I would always use event sourcing and only in a very tiny fraction of systems I would fall back to Crud.
Giovanni Asproni 00:35:08 Okay. Because I was also thinking, you know, think a bit differently. So, to me, tell me if I’m wrong. Okay to me, since that it’s mostly around enterprise applications, when we model business processes, but for example, developers that work in the space of more embedded systems or things like this, I guess they, for those kinds of systems is not necessarily a good idea to think about that?
Martin Dilger 00:35:30 Yes, that really depends. So, in algorithmic systems, like if you use operating systems, very low-level stuff, embedded systems, you need to look is event sourcing the real thing. So, where event sourcing really shines is everything about information management. So, the typical systems you see in the enterprise, you put in information, this gets transformed. You have many ways how this information is used. If you need to track how information is used along a single timeline, that’s typically where event sourcing shines. If you use algorithms and stuff like that, of course that might not be the best use case.
Giovanni Asproni 00:36:03 Okay, okay. In terms of tradeoffs that the team should consider, so between event source architecture and let’s say and call it a more traditional one. Yeah, say, so instead of even sourcing, we use let’s say relational database or well, maybe even not the necessarily relational, but without storing events as we do with event sourcing. Yeah. So, are there any tradeoffs there that we need to consider for this choice? You know, I don’t know anything in terms it could be performances, could be space on this could be anything.
Martin Dilger 00:36:37 Yes, of course there are a few. So, the first thing you need to consider when you think about adopting event sourcing is it’s a very different mindset you need. So, you cannot just tell your developers from today on we will be doing event sourcing and everything will be fine. That is typically doomed to fail. That will not work. So, the first thing you need is you need the right mindset, and this takes quite a while. It also took me almost two years to get rid of all those ideas I learned in the past and build systems, the way I build systems today using slices, it’s a very different thing. You cannot just tell your developers to do it from now on and it’ll work most probably that is doomed to fail. So, it takes a while to get into this mindset. And the hardest part with this is typically really unlearning what you have learned.
Martin Dilger 00:37:21 So building systems like this requires you to unlearn quite a few things you might think of as best practices today, which in event sourcing are simply no longer best practices. They are rather problems you try to prevent, but of course also other tradeoffs might be you need to build up the right infrastructure to do event sourcing. And this doesn’t have to be a commercial product. So, you can start very small like with a Postgres database using a relational database. I have a lot of clients that simply use a Postgres database as an event store, or some even use a Microsoft MySQL server as an event store. That is perfectly fine. So typically, the entry barrier is very low, but of course to do this right also if it comes to scale, if you build bigger systems, you need to consider quite a few things because even the Postgres database, which is powerful, if you have enough events in your system, it becomes slow. There’s something you need to consider and then oftentimes you need to evaluate, doesn’t make sense to have a commercial product. And there are quite a few commercial products available to do that, especially in the beginning that the entry barrier is really low, and many systems will never reach that scale. Most systems are rather small, so most systems don’t reach that scale where your database will get into trouble, but some systems do and then you need to consider what to do with it.
Giovanni Asproni 00:38:34 Okay. Now going back to the unlearning, what kind of things developers need to unlearn that are maybe best practices with their previous approach to software development that are not really best practices?
Martin Dilger 00:38:48 When using event sourcing, especially the combination of event sourcing and the slice-based architectures require a completely different thinking. And the one thing I struggled with the most was reuse, code reuse. It’s basically, it’s non-existent in my projects. I don’t have any code reuse because when you work with those slices, you keep those slices independent, they’re very small, but they’re completely independent. And what you can do is there is no reuse between those slices. So, you cannot just have any abstract classes. I didn’t use any abstract classes in five years or so. I never used that because it creates a lot of coupling. So, the whole dry principles don’t repeat yourself. For most developers that means, I have functionality implemented in one part of the system and that will just reuse it from everywhere. But this creates a lot of coupling and in a slice-based architecture that doesn’t work because you want those slices to be independent. So, what you do oftentimes is you copy information, you copy code between those slices and it’s perfectly fine to do that. So, building slice-based systems means a lot of copying. You copy paste, I’m extremely good at copy pasting, and nowadays copy paste means generating with AI. That’s just copy and paste on steroids. It’s the same thing. Many developers really, really struggle with this.
Giovanni Asproni 00:40:01 Actually now they say, okay, do copy and paste, but does this create issues? Like you have to change some logic and then you have to change the same logic in all the places where you did the copy and paste or the copy and paste is actually in this particular context is not affected by these problems.
Martin Dilger 00:40:19 Of course that can happen, but what typically happens is since we model the system first with event modeling, typically this logic isn’t spread out throughout the whole system. Typically, you have one slice that takes care of this. Of course, there can be something that is copied to few other slices. So can happen that you need to adjust two or three projections, for example, if you change an event that that’s perfectly fine, that can happen, but it’s not that bad as it sounds. So typically, logic in the system is very contained in slices. That’s what I’m seeing again and again. And also, I really completely lost any fear of copying also because of AI, because AI can tell you very, very well, okay, if you change this, those two or three other places also need to be adjusted. So, if you ask me that is really no longer a problem at all.
Giovanni Asproni 00:41:02 Okay. So, when rolling out this event sourcing, so let’s say in a company that has never done it before. So, first of all, well we said the technical tradeoff, but what about the business tradeoff? So why should the company consider, you know, moving whatever systems they have into a different design using event sourcing, what kind of advantages they can get out of doing this?
Martin Dilger 00:41:27 Yes. The biggest advantage, and that was also the reason why I initially went into that direction, slice-based architecture event sourcing, is whenever you work on a traditional architecture in the beginning, it’s easy. It’s no problem. That’s also the same idea with a greenfield project. When you start, it’s very easy because there are not a lot of features. You can implement those features in isolation typically, and everything is fine. But the longer you work in those systems, the more those features have cross dependencies, the more they depend on each other. What we’re talking about of course, is coupling. The longer you work in those projects, the more coupling accumulates. If you don’t invest heavily to get rid of that. So, if you don’t do constant refactorings and keep the coupling very contained, coupling just grow in the system. And this means those systems, they get slower in terms of development speed, and they get more expensive because in the beginning you build one feature and you’re good, but later in the project you build one feature, but then you also need to adjust those five other features because they all depend on each other.
Martin Dilger 00:42:25 That’s what makes late-stage development very, very expensive. So, the longer you work on those projects, the more expensive it gets. And this is where almost all companies just struggle. That’s a problem that hounds us for two decades already and much longer. And that I never found a solution to this. So, my whole career I was struggling with this, how can we do this the right way? And it was really hard, always hard until I started to work with slices. Because if you work with slices, any new feature you throw at the system, it doesn’t matter which one, any new feature is typically just a new slice. So, your architectures, they have a flat cost curve. The cost curve is very flat. You don’t have this hockey stick exponential growing cost curve. It’s very flat. No matter what requirements you add to the system, you just add new slices.
Martin Dilger 00:43:10 It’s almost like an append only architecture, just adding new slices, which means since those slices are independent from each other, you don’t touch them. They almost behave like small, tiny little microservices within your system. You only touch those slices if the requirements change. And that is such a beautiful way of working because you never have to look at the whole code base. You never have to look at, okay, what did I break now by this change? Because change is only for one slice and one slice only. This is really a great way to develop systems because your time to market with this is just amazing. And what’s also amazing is if you work with AI, and I mean every company nowadays tries to find good ways to work with AI, your coding agent never has to understand the whole code base. It just has to understand one slice. And this might be just five classes, for example. So, you never need this 1 million token context window because typically the tasks that you use for your coding agents, they’re very, very small. So, it’s a very good way to integrate AI into the development process.
Giovanni Asproni 00:44:09 Okay. And since you mentioned before, that is actually difficult to get started with it for developers and have to change the mindset and everything. So, then a company that decides to go in that direction, how would you recommend them to get started, you know, training developers or hire the right people? What is your suggestion for a company that decides to go in that direction?
Martin Dilger 00:44:31 The first step is always event modeling. So, I wouldn’t start with event sourcing. The precondition for event sourcing is some way of collaborative modeling. And my choice is always event modeling because for me, it’s the simplest way, but also event storming, all those methodologies help. There’s also domain storytelling. They are all wonderful methodologies. Just my choice is even modeling because it fits so well. So, the first thing I would always recommend is start by modeling. Start by understanding your business processes. Don’t think about technology. Start by understanding your business process. You can even do this for your Crud-based systems. You don’t have to do event sourcing to start with modeling. You get all the benefits of event modeling today with your existing system. Thatís perfectly fine. But then if you started to model those systems and you really understand those processes, there’s a natural way to transition from an event model to an event source system.
Martin Dilger 00:45:23 So if you did the modeling correct and you trained your people on doing this, this can be by workshops. This can be just by bringing in people who help them many ways to do this or just give them my book to read. That’s also a good starting point. So, there are many ways to get started. And event modeling is really, it’s a simple methodology. You getting started is really simple. But when they master that, that’s already the first step to change this mindset. The mindset changes. People start to think about processes. They no longer think about databases and tables and microservices. They start to think about processes and this changes a lot. And what you typically do then is if you have to see them model, you just have to look at the event model and you see what would be a good candidate, is there something we can extract from our legacy system?
Martin Dilger 00:46:07 Is there, oh, there’s the small process here. How about we make this a new microservice and we just make a proof of concept? You typically start with a proof of concept. You don’t do a big bang and say from today on everything is event sourcing. That’s typically not what happens. You start with a small proof of concept, one tiny little process. Let’s build a microservice using event sourcing. Let’s build a blueprint architecture. How would a blueprint architecture for us look like? What’s the stack we are using? There are many different stacks. If it’s .net, you might use Martin and Wolverine, if it’s on the JVM typically might be Axon. There are many different ways how to get started or many companies start to build their own frameworks, which is also fine. So, very easy to get started. Typically, of course, when it comes to scale, you might want to use an established framework, but just for first proof of concept, it’s perfectly fine to build your own event sourcing framework.
Martin Dilger 00:46:55 And it’s fun. Let’s face it, it’s fun to build your own framework. So why not invest a little bit of time? And with AI this can be done in one or two days. So, it’s really not a big thing anymore. And then if you have this first proof of concept that is running, maybe even in production, what you will realize is you achieved a lot in a very short period of time. So, it’s crazy how fast you can build those systems. If you combine event modeling, event sourcing, and the slice-based architecture within two days you can have a system running in production. It’s crazy how fast you can go with this. And typically, those systems since they are built together by business and engineering in collaboration, they’re exactly what those people need. So typically, they’re very successful in production.
Giovanni Asproni 00:47:33 You mentioned legacy systems. So, with the legacy system then, I guess that you would start with maybe, you said start with event modeling. I would imagine part of that would be modeling what the system currently does, at least for the parts are interesting. And then what would you do then? You choose where to start, as in, you said creating prototype or some microservices or something else to start to change the legacy system into the new shape.
Martin Dilger 00:47:57 Yes. That’s typically what happens. So, in the last month, I support many clients and modernizing legacy systems. And what I’m basically doing is I’m using AI to analyze existing systems and build event models from this, basically automatically. And this works really well. And I’m doing this from two sides typically. I use AI agents to analyze the existing code base and I use AI agents to go through the UI. So if there’s a UI, you can just use them to go through the UI and basically build the event models from the UI just to understand the processes. And you can also automatically take those screenshots, put them into the event model. It’s quite interesting. What you’re basically doing is you gather a lot of information about the system because what most companies struggle with is they have those big, gigantic systems that make a lot of money typically, but they don’t really know how they work because this knowledge is retired or it’s gone to other companies, it’s no longer there.
Martin Dilger 00:48:50 So they have a lot of information in those systems, but they don’t know how that works. And if you ask me before you do any modernization, any code, before you write a first line of code for any modernization, the first thing you need to do is completely understand how does the system work. You cannot modernize what you don’t understand. That is doomed to fail. You really need to understand how that works. And using event modeling for that is a very good step because you bring all those people together and you can extract the knowledge that is available, use AI to fill in the gaps, that works really, really well.
Giovanni Asproni 00:49:18 And instead for a greenfield system, can you have an approach that is kind of incremental? What I mean is maybe you have some event modeling workshop, but then you are not quite sure about the entire system or the direction but you know, some initial parts. Can you actually do this thing in an incremental alterative manner?
Martin Dilger 00:49:36 Yes, absolutely. So, what we typically do is we start to model, but we don’t model the whole system. And then we start, what we typically do is we model the system on a very high level, then we pick one tiny workflow that we are pretty sure about, that we understand. Okay let’s take the registration, we know how the registration works, let’s start with that. And maybe it’s just five slices. Five slices are enough to get started, write some code, build the proof of concept, bring it to pre-production or even to production. It doesn’t really matter. This piece of the software is already done. And then we can decide, okay, based on the event model, what is the next process we want to tackle? Where do we have the most knowledge now? Where are the least gaps? And then we might do that. So you can build it very incrementally, step by step. Even if you want slice by slice, that’s also possible. So yes, that’s typically the way to go. And this also gives you the possibility to change directions, so you don’t have to have those long project plans and plan the whole migration. You can go very small step by step. And if you find out well this goes in a very wrong direction, you can always change directions because it’s slice by slice you, you can basically change on a daily basis if you want.
Giovanni Asproni 00:50:38 And in terms of testability, in terms of testing, unique testing, various levels of testing, are there any differences between event sourcing systems and more traditional ones?
Martin Dilger 00:50:49 So what I’m using heavily, really heavily is behavior driven development. And that’s a very good combination together with event source systems. So basically, we do this on a slice-by-slice basis. And you do this also already in event modeling. You define basically what are the acceptance criteria, what are the business rules for one slice using give and when then. It’s just, let’s make an example and maybe that’s the easiest thing. Let’s say we have this customer registration and there’s just a rule. We only allow customers with the same surname once in the system. You would have a given event, given there is already a customer with the surname. When I try to register this customer again, or another customer with the same surname, then this might be an exception, for example. So, you describe all those business rules for each slice in the system.
Martin Dilger 00:51:37 What I do is I use the given when then specifications from the event model and I generate executable specifications in code. And this is such a great way of working because those specifications in the event model are defined by the businesspeople. So, this is the real business rules. You’re not talking about technical unit tests that test things that are not important. We are testing the real business rules that are defined by the businesspeople. And if you translate them to executable specifications and all those specifications are green, there’s a very high chance that the system does exactly what it needs to do.
Giovanni Asproni 00:52:09 Okay. And now a final question actually. Have you gotten any suggestion for matrix or signals or anything that can be used to demonstrate that, using an event modeling? Well, an event sourcing system is actually improving delivery because you see a company that invests on it say, okay, we want to invest on this thing. We have a system, an existing one, we want to go into this direction instead, which seems to be better, but what kind of matrix they should look at to the side that actually changing into an event sourcing system? They have a good return on investment.
Martin Dilger 00:52:41 Yeah, so what I use as a measurement is really, I call it the slice cycle time. So, the slice cycle time is basically how long does it take a team to build one slice. So, what we typically do is we start with an event modeling workshop that lasts typically for three days. We do two days of event modeling, modeling a process, and the third day is typically building the system. What we start to do there is we define the blueprint architecture, what does a slice look like for the company? And then what you start to measure is the slice cycle time. How long does it take your team to build a slice? In the beginning, this will typically be around two or three days, maybe with AI that’s much shorter. But what you measure is how long does it take my team to build a slice?
Martin Dilger 00:53:21 And if you do this long enough, what you will realize is this cycle time will get smaller and smaller. So, in the end it might just be half a day, for example, to build a full slice and this includes the UI. That’s a whole piece of functionality. And what you then do is those slices, they are production ready if you do it right. So, you can build those small pieces of functionality, and you can continuously deliver those slices to production. That means your time to production will be extremely short. So, you can deliver multiple times a day working software to production. Of course, that also works with other methodologies. Event sourcing is not the only thing, but a team that starts to work like this typically increases the deliveries to production massively. And that’s typically what I try companies to really adopt and know where they should go to.
Giovanni Asproni 00:54:06 Okay, thank you. I think we have come to the end of the episode. And I think weíve given quite a good introduction to the audience.
Martin Dilger 00:54:13 I hope so, yeah.
Giovanni Asproni 00:54:15 Is there anything you’d like to add, Martin?
Martin Dilger 00:54:18 I would really encourage companies, teams to give it a try. It’s not a big investment. It could be what we did with many clients was just, it’s called a FedEx day. FedEx day is just a, you take one day and at the end of the day you need to deliver like FedEx. This could be a perfect starting point. Take one day and make sure to deliver something at the end of the day. And I guarantee you, you will be positively surprised what is possible to do within a day if you bring the people together.
Giovanni Asproni 00:54:44 Okay. Thank you very much Martin. Thank you for coming to the show and it has been a real pleasure. And this is Giovanni Asproni for Software Engineering Radio. Thank you for listening.
[End of Audio]