Complexity is the Gotcha of Event-driven Architecture • David Boyne • GOTO 2024

cool so awesome to be here in Poland that's my fourth Eda day uh I've been part of so it's absolutely great to be here and today I'm going to be talking about this which is complexity okay complexity with the Venture of an architecture and complexity is this thing that will come and get you no matter what you do okay you've got the accident complexity especially as you're building distributed event driven systems the last kind of eight years I've been diving deep actually into Eda I actually built Avent driven systems found um this potential this agility

that I'd never seen before in 16 years building software architectures and systems in fact I just died deeper I worked at AWS uh to continue to just evangelize it okay and aventur architectures have this potential right and all you got to do is Google Venture of an architect you start seeing some words come up these words are like uh you know fault tolerant and decoupled architectures so we start to see you know the pretty picture up there and it's true there are many benefits of aventur of an architectures this is kind of why I love

it so much but the thing is with aventur of and architectures is this is that you inherit the Sea of complexity okay and when you can see this Iceberg and that potential the things we talk about all the blog posts you read will talk about the stuff at the top but there's so much more to get with event driven systems okay and what we can do is actually manage this complexity if we put guard rails in place understand that exists and how do we manage it we can actually then find and actually understand some of

that uh full potential so in this talk I promise you to walk away with three um different guard rails you can put in place and also uh understanding this potential itself and I actually honestly believe after years and years diving into this is if um you don't manage this complexity and at the start it won't be there but after a few years I can guarantee it will be there that you just won't unlock this potential okay so what are we going to be talking about today is this number one diving into that potential of a

vent driven architectures number two we're going to be looking at three takeaways you can take away today in action in your organizations and your companies and your businesses if you're building event driven systems if you're thinking about it there are three things to take away and finally I'm going to be looking at um the one gotcha that will get you when you build aent driven architectures every person every Enterprise every customer I spoke to fall into this trap and I'm going to explain what that is I'm going to explain how you can avoid it before

I do all of that introduce myself my name is Dave Bo um as Eric mentioned I previously was a developer Advocate at AWS for a few years actually recently left three months ago to actually focus more on tooling and open source work so I have two jobs number one is I do tolling around Aventure ofen architectures uh for free so we'll be speaking about some of that and number two actually um I de developer Advocate at Wing uh which is a programming language we're building for the cloud okay so this talk we won't cover that

um but if you're interested in any of them or seeing some demos or some stuff feel free to grab me after that that'd be great and equally I wrote something called Eda visuals uh which I'll share a link at the end but let's talk about this potential okay of event driven architectures I remember in 2022 who's been to reinvent before has anyone here been to WS reinvent okay a couple of hands so in 2022 was my first reinvent my first year as an AWS employee and uh absolute Carnage uh you know 60,000 people walking around

Las Vegas it's it's a sight to be seen and uh but I remember this year Verna vles is's the CTO of Amazon had a whole pitch on Avent driven architectures in his talk it's a great talk actually I actually recommend watching this and he said one thing one sentence in this talk that kind of stuck with me right and he says the systems that don't evolve will die okay that really got me thinking about vent driven architectures evolutionary architectures and equally the idea of static architectures kind of got me thinking about architectures that I've worked

in the past I've been part of building both and I see people building these things over and over again on the left here we have static architectures the things that hold us back the things that kind of make it slow and frustrate us as we're Building Systems now don't get me wrong we don't go out and build these architectures with this in mind but sometimes it kind of creeps up on us here on the right there push for evolutionary architectures decoupled architectures being able to add functionality over time so let's have a look at the

differences here now I'm going to tell you something here that's going to blow your minds the most scientific thing you have heard all day right that is knowledge increases over time thank you thank you look at that even get get clout no but this is the thing okay knowledge increases over time we know that so why is it when we build systems and architectures and all this kind of stuff is we have these decisions we make these decisions up front Okay so we go build something we have these decisions but we only really get that

knowledge of our domains our models our schemas our events our messages what we're trying to build later on this actually is interesting it actually has a word this word is called project Paradox okay so we start off and we build this thing without necessarily knowing the knowledge that we need to know for me this is the risk this is here is the risk of static architectures Building Systems that may kind of slow us down static architectures tend to have these different um things here number one being tightly coupled okay your architecture are hard to make

changes as time goes on yeah we also have this low cohesion decreased quality code maybe your code or your functions your services whatever they are your containers maybe they're doing too much and that's grown over time the interesting thing here is that leads to the lack of experimentation in your organization becomes hard to experiment it comes hard to integrate with new AI llm models or whatever it is you want to do because the systems are so kind of coupled and and uh static I guess in a way and finally here it's about the team independencies

so we try to make change in our architecture but we talk to team a and Team B has talked to Tina we need to make a change to this particular contract okay to do that I need to talk to John John's over here in this team that's fantastic it's only a schem of change but why is it taking us three weeks or four weeks to do that because everyone's got different priorities different things going on all the time so it becomes a very interesting thing because you start to have this frustration that happens in the

organization with your architectures and I've been there in the past I've worked on teams and it's very is very frustrating everyone's there to do the same thing we're there to serve the business I guess at the end of the day but why is it that Tech is not the enabler that we want it to be why is it taking so long to implement something okay this is kind of that nuances and this is the thing that feeling that I get when I see and I continue to see today people building architectures in that particular style

so if we take a step back for a minute there's this report out earlier this year's Gartner report that I read it says about 60% of organizations are focused this year on Speed and Agility okay it's an interesting time actually the it Market at the moment we have like um various different things happening all over the place but that Speed and Agility is an interesting one especially as we look at things like cursor Has anyone used cursor the new uh text editor a few people right you can instantly create applications like you through commands and

all sorts of things co-pilot Amazon Q whatever you pick your take your pick but the interesting thing I think is going to happen here is like the business is going to expect some kind of agility as we see these tools making us faster and faster so if we go back here and think about Speed and Agility well how can we do that when we're at risk of the static architectures here and I believe to be honest what we need to do here is actually try to defer our decisions later on okay and we can do

this with event architectures with our messages with our events that we raise we can build an evolutionary system an evolutionary architecture and and one of the principles of evolutionary architecture actually is to enable incremental change so now if we look at the characteristics here versus what we had we see the words Loosely coupled coming up okay easier to make changes High cohesion maybe we have services or small things doing one thing and one thing very well this is possible and equally here we a platform to experiment okay this is pretty cool stuff so an example

here is we have an event one thing I like to promote is actually raising events when you have no consumers your events some of these events are going to be domain events business events that an order has been placed as an example or someone's just checked out something or whatever it is we can raise these events we can evolve as time goes on we can have Downstream consumers in a month's time six months or a year consume these events and have this evolutionary approach to our organization then finally here team dependency if you can find

the events discover the events understand the schemas and the context of the events and the messages why can't I just consume it okay an event bridge is an example of that as I use AWS services or any broker in fact we can raise these events and consume them so I actually believe that evolutionary architectures can lead to Innovation okay and when you lower that cost of integration between systems you create you can create explosions of innovation so when we compare the two the static versus event driven versus evolutionary architectures there's this thing where it's kind

of like okay well static architectures can lead us to frustrations and the other side here we have aventur of an architectures could be an enabler now there's one problem with evolutionary architectures and Avent driven architectures in general is in fact they lead to complexity actually quite difficult let's have a look at a basic example okay so we have an order service here we have a channel in the middle a broker a eventbridge s ssqs or Rabbid mq or cfco doesn't really matter we have consumers here on the right consuming that message kind of a pub

sub pattern here we as the order team today have been tasked to raise an order placed event fantastic we've just read online on serus land or whatever else how to do this in fact we can use event bridge and manage Service as an example that that barrier to entry is lowering every day every year so we say yes we can do this let's go and do this as a team so what we start to do is we start with an event okay so we look at the documentation we say yes fantastic we have a detailed

type the order has been placed I think that's a good name in convention okay we have a source in event bridg this is a way I guess to map like groups of events I tend to use it as domains so the orders domain is raise this event or the service fantastic we're on a roll down here is the schema is the payload this is up to us as a team to Define so simply what's what can we do we can add the order ID and the user ID in here no harm done right so we

move move on so we raise an event we have consumers in fact this managed service has done all of this for us fantastic we just need to raise events onto it so three months 3 weeks whatever it is comes down and we got another event to raise this's team over here the business want to know when an order has been cancelled we want to send some emails as an example well we've done this before we can do it again so we go back we copy and paste some code we have a schema an envelope a

message that we can raise so now we have the order cancelled event and we have some new properties property number one is the reason it is no longer needed now this might be useful so the the email system you canceled the order because you said it was no longer needed here we have type tww when you cancel an order okay the type tww here does any know what tww means when you cancel an order no one in the room I don't know what it means I made the slide okay but what's Happening Here is implementation

details of this service have started to leak okay it looks harmless but there's consequences and down here we have a user object we have the ID the first name the last name but remember that other event that we had we just had the user ID so why have we got an object now is this pii information should consumers even have first name or last name don't know don't care so we carry on we're flying okay we've got events now we we have a new event order updated event we can just keep going in fact we

go to the Whiteboard and we start drawing boxes and lines because it's like we like to do this as Architects and Engineers to our CTO to just ify our jobs it's fantastic and in fact other teams start to look look look at us and think some cool stuff going on here I want some of this I'm going to be a consumer of your event and we keep building up on this system more channels where we're using sqs eventbridge we're using rabbit mq we're using Kinesis and Dynamo streams all sorts of things in fact more teams

come on board and say yes this is fantastic absolutely look at this decoupled beautiful architecture with lines and boxes and channels and event driven just come back from Poland and look what I've built but nine times out of 10 what we have built is just a big ball of distributed mud okay and complexity coming back to complexity lies within the Lines within the details within the way we can consume messages and publish messages and talking about complexity here let's have have a A visual representation of complexity in how fast it can grow so here we

have three nodes one two three this could be three of us talking after this this could be three of us in the pub this could be three messages three Brokers three systems doesn't really matter the three possible channels in this diagram so we do is we had two more notes here so we got five so now we have 10 channels of communication okay so what happens if we had two more we go to seven now we have 21 different channels ways possibilities of communic communicating with each other again seven people in a pub is the

conversations are flying so what we do with Aventure of an architectures is we start to lean into channels and Brokers to manage this for us we start to use EV vent Bridge as an example AWS solution say okay I'm going to implement some managed policies you can't talk to whoever you want I'm going to introduce some of this stuff which sounds again sounds fantastic on paper we start to draw this up again A B and C channels now this looks simple but again that complexity comes in the details number one unclear domains what is a

what is B what are our domains what are our contexts of these domains number two here is schema definition okay how do we Define our schemas how do we evolve our schemas how do we change our schemas backwards compatibility all these issues that will arise it's just a matter of time here one of my favorite ones is how we consume messages right can couple you directly back to the producer so what can we take from domain driven design and help us here and then another one here is language language that's used between domains between our

messages between our models you know a policy over here on the order system can be completely different to a policy over here on a payment system okay and you often find these things so how do we deal with all of this what rules and what things can we put in place and I believe there are guard rails here are three guard rails you can put in place number one is understanding implementation versus behavior and what we can do here number two is about event evolutionary strategies how do we evolve our events what options do we

have and number three here is about defining some kind of mappings between consumption of EV so first one here is about understanding Behavior versus implementation so you may be kind of uh energized after Poland uh Eda day and go away and start experimenting with some of this stuff you've seen today start implementing as I said earlier that barrier to entry is lowering every year there's new Sask providers pass providers coming out in the vent driven space at the moment meaning you can literally pump messages to to cues that you don't control and be start becoming

event driven so there this implementation phase that we we're excited about and we want to do what tends to happen you you fall into this weird and wonderful trap you start to implement right we have value over time when we implement we start to have our initial producers and consumers there's this bump in value that you get you start feeling great because we raised an event we've got a consumer and things are working for us okay okay we have more producers more consumers over time and that's fine but you start to realize after a while

this could be a year or months whatever it is is that value that you initially got tends to Plateau now why is that well let's map complexity onto the same graph so here what tends to happen with event driven architectures is that complexity seems to come it's this thing that's hidden seems to kind of come out the darkness and it's just all of a sudden there so here we have the initial producers and consumers and then assumptions start to get made assumptions about the domain the models the schema Evolution strategies the consumption strategies whatever it

is how do we know who's producing what who's consuming what that's a big problem there an interesting one really if we talk about understanding okay okay and that implementation first mindset and this is a great quote um from the author of event storming but he says it's often the misunderstanding that gets released into production okay now if we applied that to event driven architectures and that implementation first you see this all the time so what happens if we actually take a step back and understand Behavior first with event driven systems what can we get when

we talk about Behavior first we talk about understanding the behavior of the system that we're trying to model we identify events as we identify events we work with and collaborate with domain experts right events can be business events events can be uh technical events whatever it is but we need to map and visualize this somehow can really help you understand what it is you're building especially as you kick off or even Explore your event driven systems then finally here is talking about language that's used in the organization I can't tell you the amount of meetings

that I've been in doing this mental model Just Between the same model literally models and language um in these meetings examples being you know we're talking about policy but you call it something else but we're talking about the same thing and with event architectures we can actually embrace that one way we can do that is actually using something called event storming has anyone done this before cool so a few people back all over the room so two things you can do event modeling and event storming can really help you so workshops you can use and

you can run with your organization workshops you can get your domain experts into a room and start mapping out your system understanding your system using commands using um reads and using uh events as an example in mapping them into domains it's a fantastic and interesting Workshop to run and most of the times it's actually the part I like the most is actually the arguments that we have between each other understanding the nuances between the naming conventions here's an example I like to share uh when I do this uh do these talks but this is a

basic example of a car park system so we build a car park system I come in I grab a ticket from the machine and I park my car now it also allows me to extend it on the mobile phone right so I can extend the parking if I'm out with my kids which is fantastic for people that actually support that and then we have the system now most people in this room probably haven't seen this before but I guarantee most people in this room can work out what's happening so the top here we Define our

system the ticket machine the ticket machine raises a command a command is a type of message in our event architectures a command can be rejected or accepted please create me a ticket no we do not have any spaces that's a rejection that's fine commands can be over HTTP as an example here that could be a synchronous request if it succeeds the service can then admit you know publish out to say that the ticket has been created consumers may or may not be interested but this service has done its job equally we can also update the

car park spaces we can emit this information to the system we wrap this in a domain this is the car park domain we're dealing with spaces and car parks and all sorts of things next we have parking sessions we have uh the customer and extending please extend this session and we can raise Events off this so we have these different boundaries bounded context different messages communicating between these boundaries this event storming is a is a fantastic way if you're just starting out with your Eda or you want to picture your system I highly recommend checking

that out and there's resources at the end to help you do that what I'm trying to say here is that think about Behavior first thinking you know just put some energy into it when you build your Avent driven architectures rather than diving in and start implementing it you can save so much time just thinking and doing some upfront design especially around the behavior the next thing here is one they seems to trip people up all the time people don't often think about it is about event evolutionary strategies how do you evolve your events now it's

an interesting thing about Eda and apis and events and apis open API specs and all sorts of things we spent the last 20 years nurturing and loving our apis you try and go to a company and Implement a new API I can guarantee they've got 101 different um governance strategies to do that and events on the other hand not so so many people people come up and they think you know how do we evolve our events how are we going to change this who are the consumers how are we going to break things and events

are an interesting thing if we take a step back for a minute why do we even care about events I don't have an event driven system I guarantee you've got events in your system I guarantee your business probably care about kpis and events so I like to think of events tell a story okay to think about this you know I woke up today in this hotel actually what did I have for breakfast how did I get here what 's I talk what's the rating on the thing all these things happening what did you all eat

for dinner all this kind of stuff these are events that are emitting think about your system who's checking out who installed the C package uh who's dropped off of on your system who's just paid all these kind of things are events that your business may be interested in and equally on the other side we have tables and state of information so if you query me which sounds as weird but if you'd query me you would see uh that I'm on the stage right now doing this talk and modern applications tend to have both events and

state but with events it's like how do we version them okay how do we evolve our events now most businesses you hope don't kind of uh stay in place we evolve and our messages our schemas evolve over time so we start with version one and then we go to version one two and two we follow sver versioning because we're told that's the best thing to do awesome great fantastic now at this scale this is pretty pretty easy okay so now remember we are event driven and we have more and more events in our system and

we scale this out we have versions one and 01 and two and five and 5.1 and it's kind of how do we evolve these events without breaking Downstream consumers and without even thinking about this and most as I said most people trip up here but thinking about your evolutionary strategies you will come to a point when you're building your event architectures you're just going to start breaking things now what options do you have here well there's not one option that rules them all unfortunately but we have options so number one here is are we going

to be backwards compatible is this what we decide as a team as an organization for our schemas to be backwards compatible okay are we going to not introduce breaking changes are new Fields going to be optional in our schemas again this is another thing we can look at equally parallel versions is a good way of doing things or can be a good way so version one and version two who's consuming the event we don't know okay so um we're going to publish version two and version one and deprecate version one over time this could work

for you when you talk about EV event strategies event schemas everyone always comes up with this John post's Law and there's some value here for sure it says be conservative in what you do and liberal in what you accept from others okay now this is great when we apply this to EV vent driven architectures and messages be liberal in what we do we means keep Simple right why do I need to send the orders and the users let's start simple be conservative in what we're do and be conservative in what we send Downstream start simple

now there are caveats to that caveat number one one being if your channel eventbridge as an example or sqs whatever or cafka has filtering capabilities as an example we can't do much filtering on this we don't know the user we don't know the order so a tradeoffs to consider equally as a consumer is being liberal in what you accept this event comes in as a consumer I'm not interested in address I'm not interested in payments I'm interested in orders orders is the only I am going to validate again being liberal this allows us to be

more flexible why do I need to validate that whole schema when this is the only thing my service cares about so takeaway two here really is just thinking about this thinking about defining a strategy thinking about this upfront again can really just help you and save time the amount of people when I was at AWS customers I spoke to about event bridge and all sorts of things um get to the point where they find it hard to evolve this stuff is because we've not done enough thinking or planning about that so I really recommend just

thinking about what's the right solution for you and then equally the third one here is actually one of my favorites is actually complexity comes in the way we consume messages okay and so this is um some stuff out of domain driven design but I think this can really help us so an example would be I am the order service and I share with you the order has been placed you are all consumers you you're you may be interested or you may not when you take this service you are a conformist you are conforming okay you

are taking my model my order what I think is right in my context you can apply it in your consumer now this might be okay you might think yeah we understand orders we understand what this is this equally can lead to this complexity nightmare one example being here is an order that has been placed and then Downstream in a payment service we start to consume that order model the order model all of a sudden is everywhere in our code the properties are in our code and guess what when we change that order model we're going

to break down stream consumers because we're tightly coupled in contract again going back we draw the boxes we think we're decoupled but all we've done here is really couple ourselves so what can we do there what ways and things can we do there we can start introducing anti-corruption layers might be a good option to be able to take that message and transform it into something we understand so we take that order place thank you very much but I am going to protect this domain you can't talk to this I'm going to model you into something

that we understand our team understands we're going to control it out this boundary again this may be an option for you it may be too much you may not care the other one here is open host service so we push back onto the consumer the producer sorry and we say to them we agreed a contract we agreed a contract up front and that's what you have to do that order object that order model we agreed is an order for the business and that's what you agree so you map it and then you send it open

host service pushes back so these are called bounded context mappings in domain driven design there's like 14 of them I recommend diving deeper into that the question is which one do I use well it depends on how much communication you want conformist requires High communication I've just changed the schema you need to be aware we may have a meeting about it you may be the team sat next to me remote or whatever it is we got this this coupling through distance we're very tight you know we're very tight team or organization that might work for

you down here is open host service requires less communication upfront because we can push back you know we push back on that producer have that initial meeting and we're done so it really depends on what strategy you want to use depends on that level of communication that you have and that you want equally it's about controlling complexity with distance understanding this can help private events versus public and integration events in adventure of an architectures you know as you use eventbridge or you use the Brokers or Kafka no one tells you about this stuff but you

start modeling in this particular way so we have private events we are the order service here and here I going to send you an event that type tww is in the event but it doesn't matter because we understand it okay the model is completely different integration events we're integrating with third parties we've just created an API that other people can buy using messages fantastic these schemas are completely different to the private event schemas but we're using the same technology same channels same boxes same diagrams but the context is completely different so just controlling and understanding

that complexity that that that distance itself um has an impact so here the three things like three guard rails you can put in place right it's just understanding Behavior first thing thinking just consider this understanding that event strategy how are you going to version your events think about that and equally defining a coupling strategy when you consume an event off your event bus do you want to conform is that a problem is it not should we create anti-corruption layer should we do something else so there are the three things you can take away and there's

one thing left in this talk really which is about the biggest gotcha of them all the biggest thing that will get you no matter what you do as Eda I speak to many many people uh fall into this particular trap and uh it's it's actually quite fascinating to see so going back to this diagram we got our boxes our lines we've implemented some guard rails we wash away that big bowl of mud and fantastic we feel great about ourselves this is awesome but again as I said there's one thing that will get you and will

bite you and complexity will come for you and we often see this when we build build a venten architectures okay these practices that we're taught is that producers should not know about consumers okay interesting technically yes this is fantastic this keeps us decoupled I don't have to talk to this team over there to tell them that an order has been placed great so what's the problems that start to emerge well people come and go in the organization that tends to happen the first questions we're asked we we let's say we're tasked to build a new

system or AI system whatever it is uh the first question that some Engineers might ask is what events do we have okay and most the time the answer to that is well you can just look in GitHub right I can send you that GitHub link you can kind of see what events we have fantastic okay well what are the payloads of the events well the schemas well I've just sent you the link go away fantastic also the interesting thing is who's consuming what so I produce the order placed I have no idea who's consuming this

because I'm told that producers don't need to know about consumers so I've taken it literally I have no idea who's consuming it if anyone is you may have some metrics and observability if you're lucky but it's an interesting thing and it doesn't what I kind of get at here is really is that it doesn't producers should know about consumers yes but that doesn't mean we can skip governance and governance in event architectures is often overlooked as I mentioned apis been doing it for 15 20 plus years governance is everywhere open API specs the whole shebang

but with Eda we're kind of at this weird point where we're still trying to figure this out so what options do we have well thankfully we have some open source Solutions number one up here is cloud events so a specification that allows you to standardize messages between channels and systems Cloud event uh guy at the back um but yeah this is fantastic so the way I think about this which I love is I think about event driven systems in the future as we connect to streams of information between organizations how are you going to standard

standardize these schemas or Cloud events again can help you here a as kpi has anyone heard of acing kpi no one actually awesome so acing kpi is a specification uh a friend of mine uh Fran Mendes he worked at New Relic and found a problem years ago that we just didn't know who's consuming what who's doing what and all this stuff forked open API got funding for the project and now it's under the Linux Foundation what ASN kpi allows you to do is document your services document your channels document your messages using schemas using afos

schemas using different bindings okay interesting because when we have specifications we can start building tools okay so here is a specification example on the left we have the operations that the uh uh user signed up and we have the different channels this could be a Kafka Channel as an example how can I connect to that well the details in there so when we start having users in the future it's like well if our services had these files it could help here on the right because we have a standard specification we can start rendering this out

in HTML we start hosting this fantastic and this leads on to something where uh an open source project I'm building at the moment uh to help with all of this because I'm super passionate about this has anyone heard of event catalog just out of curiosity c a few people um this round observability it's like helping people this is free to use MIT license um but it's like how do you solve some of these problems and that's exactly what event catalog does it allows you to document your Aventure of an architectures using markdown allows you to

visualize things down here using components allows us to search things we have uh visualizers here we can actually visualize Services messages commands and queries okay these questions that come up that I saw kept coming up is like event catalog aims to help with this if catalog here also has different Integrations cafka eventbridge open API Asing Ki okay sdks if you want to automate some of your cataloges so just remember what I said about that is that that then problems who's consuming what who's producing what where are the documentation this is exactly the vision for the

project and if you're interested in joining along again this is free open source I do this um on the side at the moment but we have almost 800 Discord members 50 contributors and about almost 17,000 catalogs created so far so if you're interested come along to the Discord um and hang out with us um and see what you think but finally here is just a managing that complexity okay with documenting and governance again can really help you this is something that's again often overlooked I'm speaking to so many people at the moment so many Enterprise

customers it's normally happens at scale later on as you build Eda but governance and these things will come and that complexity will come but thinking about it today walking away from from this session just just just just placing that seed again can just really help you consider some of this stuff so with that I just want to kind of summarize this talk U we spoke about designing for evolutionary architectures the static architectures that you may have resonated with you may have not I've definitely seen them in the past I've definitely seen benefit of evolutionary architectures

and event driven architectures in fact that that agility and that passion actually got me uh diving into this for like the past eight years just consider setting some guard rails right just think about that think about what can I do to help this system grow because I can guarantee complexity and if it doesn't please call me up on that but complexity will come at some point it's normally around business domains and people and all sorts of weird and wonderful things again in that detail of them boxes document your event architectures you know I again I

just I have people like doing that at the moment that just really helps them out and again what I said at the start is that potential of event architectures is there I think it's fantastic I love this event I love event driven architectures um and I think if you manage that complexity put guard rails in place think about it you can actually get more potential out of your system you know when you have these problems in the future you may turn around and say Eda wasn't for us but in fact maybe it's more of we

didn't manage that complexity maybe Eda can work for us here are some resources for you so I here's a free kind of book that I built ages ago called Eda visuals you can download this for free it's like 60 visuals of of and driven architectures I've been diving into so feel free to grab that and then all the slides extra resources videos content everything everything I mentioned in this talk is on GitHub and you can find that here and I just want to say thanks very much uh if you want to talk feel free after

or c me out there and I appreciate your time thanks a lot