Speaker 2
I'm glad you answered that one because when I was writing the tweets, I didn't quite realize the difference between the two. So I wrote one that had event sourcing and Chris actually pointed that out to me. He's like, are we talking about event sourcing today or just event driven? So does that answer your question, Chris, or do you have more?
Speaker 4
No, I think that answers my question. I think the other thing that's important there too is that there's a distinction between the two a little bit of event sourcing and event driven. Like you don't have to do event sourcing to do event driven, but and you don't necessarily have to do event driven if you do event sourcing, it can be useful on its own, but it's important to not conflate the two or you'll wind up in a really awkward world.
Speaker 1
I think most of the time. Totally. We probably should have started off with that. They are extremely similar and they they work with each other as well. There's quite a few like these sub architectures. There's like CQRS as well. There's like for like there's like saga patterns that you can utilize and they all kind of work together. I just look at it as really event driven is the big one. That is like an umbrella term that basically encompasses all this other stuff and there's like different ways how you can, you know, utilize it basically and a while them is like event sourcing.
Speaker 2
So you both mentioned, you know, replaying, you can technically replay events, especially if you just want to like see it a database or do some testing. In my mind, this seems like something that would make a lot of testing simpler because rather than like having to spend six different services up and make sure they interact correctly, you can sort of just, it's almost like a unit test where it's like, here's the input. Does it emit the event? I want it to emit. Is that generally what testing ends up looking like? Totally.
Speaker 1
Here's some anecdote time really quick and it was awesome. It was, it was the first time I ever experienced this, like in my entire career where basically when we were building our company and we were building out the architecture for it, we didn't actually have a database behind it for the first six months, I believe. Everything was so event driven, say that all we did is basically just write features, emitted events, you know, had another service consume the event and then we moved on. And because you're utilizing some sort of caching, because you still need to bootstrap your services, right? Like, and you need to keep some sort of state within the service. So you, we would use a CD behind the scenes and we would basically, as we, you know, consume an event and we want to say, say that like, oh yeah, this event has been consumed or we've done something with this customer, save it to a CD service starts back up, loads it from a CD and we're back into the same thing. So in that particular case, then so a database and this, these concepts of having to see the DB and so on, they're all basically gone. You don't really need to do that sort of stuff. So in regards to testing things or whether it's like actually part of your CI and so on, yes, you're essentially just emitting events, you rarely will have to like do some sort of DB mocks and so on to actually, yeah, perform your unit tests or integration tests.