This pattern is crazy, or I'm an idiot - Learning Domain-Driven Design by Vlad K [31:29-36:31]

Exactly. And again, there's trade-offs because some of these are compatible with other things, like if you have a highly synchronous system versus asynchronous process, choreography versus orchestration, all of these things, you end up becoming, your Saga's can end up be a beautiful way of doing things in a correct path, or they can be, I mean, again, self-architecture of the hard parts has the one called the horror story, Saga, right. Which is sort of like worse to both worlds, or you had this sort of distributed monolithic thing that actually can't guarantee correctness. And you can, you know, you can set this up really poorly. And so I think reading books like this are helpful because, you know, in some cases, using a centralized coordinator is really nice. Orchestrators are very common, especially in like things like DevOps, where we, you know, we do want to have a single state machine that understands this sort of state of the stuff, but you get to a certain size and scale where eventual consistency is okay, and you want to decentralize things and you want to have event-driven architecture where it's eventually consistent across the entire system. But then what it unlocks for you is the fact that you can go horizontal to, you know, levels of compute that just not possible with an orchestrated. Right, right. But yeah, but there's trade-offs. And I think, again, books like this are excellent for understanding what am I getting myself into. Have you worked on a big like distributed system like that? I've never been, I've never been on teams large enough to do full one. I have support. I've been in a company that had some of this in place, but I was not on those teams. So I would kind of like be a fly on the wall. Have you? No, well, I mean, this is one of those things where like we did a bit of this at my last company, but we kind of had like a whole like data team that was playing a lot more in like the event-driven world. And I was a little more on kind of like the nuts and bolts crud side of things. So I haven't had this. And then when I was at, you know, the big cloud provider, that's one of those things where it's like, you learn a lot if you kind of go like the thing direction, but also so much of it is abstracted away from you. Right. There's so much kind of batteries included out of development there. And I kind of wish like, I don't know if I'll ever go back to like a big thing as company. I don't think I'll ever move to Silicon Valley. And I don't who knows what remote opportunities look like. Right. But I kind of wish I could go back, especially now after we've read so much. Because I think there's a lot, I think I'd be a lot more curious. And I think I would learn a lot more about how things are done at that scale. Or as I think when I joined, I was it was really good opportunity. And I was very excited. But I think there was a little too much of me just like trying to keep my my head above water. Yeah. Yeah. I'm better equipped these days. And I will say the environments in which these things are implemented well are largely invisible. Like so, especially. That's true. You mean I even realize how sophisticated you know, your events we're seeing work is because same defaults are put into place. These things are just available. You may not even understand why your service is able to react to everything else. And the software architecture side of this becomes incredibly important. And again, we also have like a really there's a big moving target. It's funny. Like, Kafka's been out for a while now. But I still feel like there's folks that are in being introduced to these patterns as they come up. And we're actually again, we're doing this as well where we're trying to understand the daily sort of transactional needs of the business with data that's coming in. And then we also have these long term lake house sort of analytics stores that we have. And we've realized that Kafka actually would service quite well where instead of us having to have pipelines that kind of go into the lake house and go into the business and kind of have a dependency graph on each other, it'd be much nicer if we could ingest data from the outside world and write these events that these things happened to a Kafka queue in which the analytics warehouse is like cool. I have a bunch of data. I can slurp up and we'll shove it into there. And then this event system also says, oh, cool. There's like daily data that the business development team needs in their CRM. And both of those can just have their own consumers responding to this thing. Yeah. Yeah. And so that's that's the direction we're going because we realize there's a bunch of stuff we're doing in these Kubernetes clusters. There's a bunch of