The Art of EDA Visuals: Exploring Concepts Through Graphics

Elevator Pitch for Event-Driven Architectures

Eric Johnson: Hey, my name is Eric Johnson, and welcome to "GOTO Unscripted." You've probably seen us before. I'm a principal developer for serverless at AWS. I work for AWS. Dave Boyne, tell them who you are.

Dave Boyne: Hello, everyone. I am Dave Boyne Boyne. I also work at AWS, focusing on serverless, venture and architectures, and things like that. I work with "the" Eric Johnson.

Eric Johnson: "The," I like that. I like that I have an article of "the" Eric Johnson rather than, you know, "a" Eric Johnson. So, yes, Dave is also a developer advocate. We both work for the developer advocacy team. And today we're gonna talk about something that pairs up with serverless a lot. It's almost interchangeable. Not quite, but that's EDA. And if you don't know what EDA is, and I warn Dave, I want you to define EDA. In a nutshell, do the elevator pitch, what is EDA?

Dave Boyne: Event-driven architecture. EDA stands for event-driven architecture for those who do not know who is watching. But it's a way of communicating between systems using messages, I guess, using events. I mean, this thing, if you look at the high level, you tend to hear things about producers and consumers and channels or brokers and topics. But I tell you what, as soon as you, you know, uplift it, you dive into so many details about event-driven architectures. And many people are using them because they allow us to build decoupled, scalable, resilient architectures. But as I said, you know, there's tons to cover in this space. And hopefully, we're gonna cover some of that today with Eric.

Eric Johnson: I'm gonna climb into a little bit, but I wanna show you how I define it, okay? So what I do, this is what I do. So when you think about event-driven architecture...First of all, Dave 's is better than mine. So I'm not correcting Dave in any way, shape, or form. Dave Boyne, while it doesn't look like it, is infinitely smarter than I am. Well, let's not go infinitely, but somewhat smarter than I am, especially in this area. But I love to explain it. When you think about when you build architectures, people do APIs, they're polling, they're calling. In event-driven architecture, it comes down to this, and you'll wanna write this down. So I'll pause and let you get a pencil and paper. Okay. So here's how it works. Something happens, and we react. That's it. Dave Boyne, what do you think? How was that?

Dave's kind of the expert in this area. He's one of the thought leaders and has done a ton of work around explaining EDA at a colossal scale. I mean, he's written all kinds of...you know, I don't know about books, but he's written all kinds of blogs, he's done videos, he's done speaking. Shameless plug here, if you're watching this before May 14, 2024, Dave Boyne will be keynoting the actual EDA Day in London. So if you're interested in that, look it up, EDA Day, London 2024, Dave Boyne keynoting. 

Dave Boyne: But the reason we're here today is we're gonna talk about this massive volume of information Dave has put together in what we call EDA visuals. Dave Boyne, what prompted the visuals and why do you do it? What are you doing?

Recommended talk: Event-Driven Integration Today & Tomorrow • James Urquhart • GOTO 2023

The Evolution of Learning Approaches: Zettelkasten Method

Eric Johnson: But the reason we're here today is we're gonna talk about this massive volume of information Dave has put together in what we call EDA visuals. Dave Boyne, what prompted the visuals and why do you do it? What are you doing?

Dave Boyne: What are you doing, Dave Boyne? Yeah, so sure. I kind of...so last year I started this project called EDA visuals. So a few years ago, I started diving kind of deeper into event-driven architectures. I was actually...before I joined AWS, I was building event-driven architectures with leading teams. I kind of found, like, the paradigm and this architecture that just made sense to me, right? And I was kind of like, "Wow, I need to dive deeper into this," because I saw, like, agility that I've never seen before. So I dive into EDA and cut a long story short, so last year I started reading a lot more books, a lot more content over that time.

Eric Johnson: I'm so proud of you.

Dave Boyne: And there's something called...so I started trying this whole second brain thing, right? I don't know, Eric, have you heard about this, people have second brains.

Eric Johnson: No, no. You're gonna have to fill me in on this. I have no idea what you're talking about.

Dave Boyne: There's this whole, like, movement...It's more popular now actually, than it was a couple of years ago. But the whole idea is, it's, like this note-taking system that can help you collect information and also find links between information and even kind of write content around this information. So I'll give you some examples. So there's one in particular I follow called the Zettelkasten method. Okay. Have you heard of that? Is this new?

Eric Johnson: Let's say I have.

Dave Boyne: Okay. So the whole idea of Zettelkasten means note box, right? And it's popular by a German sociologist called Niklas Luhmann. I think I got that right. In his lifetime, he wrote 70 books and over 400 articles. And people were saying, how can you do this, right? This is before computers, I believe. So he developed this note-taking method. And you can see this online, and I'll probably share a link actually to his video. But you can actually...the whole idea anyway, is you read something, and you take a note about it, right? And the note has to be something, you're not copying it, but the note has to be, what do you find interesting about this? So if I'm reading Eric's blog post on event-driven architectures I will think why is that important to me? So then I write this down. And what I'm getting at with this is you end up with these notes. So, like, 10 different notes, 10 different blog posts, whatever, as you consume and you learn content. The whole idea is then you kind of transform them into what they're called, like, permanent notes. So these are literature notes. So what happens is you get these notes, and then you transform them into something bigger or some collected vision. An example would be, Eric, who talked about, like, facts and events, something happened, we listened to it, right?

Now, if I was reading some other blog posts, maybe about some serverless stuff, or maybe some community blog posts, whatever it might be, or might be a Kubernetes blog post, whatever it might be, someone also talking about events or messages or this kind of stuff. And you kind of interested as you go through these notes, you find connections between the notes. And then you put these in something called a permanent note. And then from a permanent note, you can write blog posts from it or books from it. And the whole idea, this whole thing is just a collection of these notes just growing, growing, growing.

So I've been doing that for about a year-and-a-half now. So I have, like, one...a perfect one is around event design. So what goes inside our events? So about actually 18 months ago, we had our first EDA Day in London, and I did a talk about event design. And I use this method to kind of build up this talk. And now I have these permanent notes where I can go back and learn all of this stuff and create more links. Anyway, how is this relevant to the visuals that I've done? So what I decided actually...

Eric Johnson: I'm gonna stop for a second because, honestly, I thought we were just gonna be talking...of course, this is unscripted, so you never know where we're going. But I thought we were going to be talking about the EDA. But this is fascinating, especially...Okay, and I know Eric Johnson always...If you know me at all, I joke a lot. But I have the worst memory on the planet. I mean, I just don't retain things. And so this is interesting to me, especially in our industry, right? I mean, golly, there are 372,000 services on AWS, don't quote me on that, that's probably not the right number. But there are a lot, you know, and same with the other clouds, and same with, you know, the languages and the syntax and things we have to retain.

And so this is interesting to me because I've seen Dave...So here's what Dave is an expert at, and this doesn't mean I like you, okay? I'm just gonna say these are facts, not emotions, right? Dave Boyne puts it into practice as he learns, and he does it in a cool way. In fact, like, when we talked about gen AI when gen AI first came out, you started learning how gen AI works. And then you wrote the storytelling application that...Do you still use that? Do you still tell your kids stories with this?

Dave Boyne: I still need to figure it out, but I want to use gen AI to...My son is into "Harry Potter," right? So I wanna use gen AI, "Harry Potter" trivia questions, and print it using...You know, we built this application called Serverlesspresso. If you've not seen this, it's a coffee-making service app. But with it, we have a printer, right? It prints out receipts. So what I wanna do is put this printer in his room. And every time randomly during the day, I wanna use gen AI to print a trivia question about "Harry Potter." So this is the kind of thing you can do the gen AI. Yeah, so that'd be pretty cool.

Eric Johnson: That's super cool. Yeah, that's super cool. I didn't mean to take us astride, but...or take us astride? I don't know what I meant by that. But I don't mean to take us off the path here. But the same comes with the EDA as you were...I love this idea as you were...I mean, you've always, as I said, kind of been ahead of the curve on EDA, you have this really good understanding grasp of it. But it's been interesting to watch you learn more and share more through this process. So anyway, I just really love that approach. Dave Boyne never learns in a vacuum, he always shares what he learns constantly. So one of the reasons, you know, I was here before Dave, and when we were talking about hiring you, Dave Boyne, it was, like, you're constantly pouring into the community all this stuff. And I love it, so.

Dave Boyne: Yeah. I think that's something I thought about recently...We're kind of going off a bit topic here.

Eric Johnson: That's okay.

Visual Learning and its Impact on Education

Dave Boyne: But is around the book...and bring it back to EDA, is it's so easy as a developer advocate, and Eric, you probably know this because we're surrounded by leaders in the space. We are surrounded by customers doing a lot of cool stuff, and a lot of businesses doing some great stuff. It's so easy to kind of be in this echo chamber of people doing this, right? So event-driven architectures, I speak to many, many people doing this, doing it great. But the key is really that what I find with the visuals, with the content in general, is you need to step away from that and figure out, okay, well, there's so many people, the way I like to visualize it as a mountain, right? So we think we're at the top of the mountain, we're probably not. But let's say we were around the top or whatever else in this bubble, there are so many people climbing up and trying to learn about event-driven architectures. And that's where I kind of put my efforts in with the visuals as an example, just okay, here's how you do that. But going back...

Eric Johnson: It's breadcrumbs.

Dave Boyne: Exactly. Kind of teaching people. But going back to the Zettelkasten, so what I decided to do in the visuals last year for myself is, like, how can I...so I'm writing all this stuff, I'm learning about cloud events, bidirectional events, I'm learning about all this stuff, which is cool. But I'm a very visual person and I like visuals to help me learn. So I started creating visuals for myself and was like, okay, let's talk about cloud events, which is my recent visual. What are cloud events? What is the binary mode? What is structured mode? What are these different things? And what I find is when you visualize it in a bite-size chunk, you can look at something in this note-taking system and see like, ah, okay, that's what it was. And then one day last year, I just decided to share a visual on Twitter and socials, and people seem to, you know, love them. And then since then...

Eric Johnson: I did.

Dave Boyne: ...I just shared them, I wrote a website on serverlessland.com. So I created a new page on here and just put visuals on there. And every...you know, I was doing about one a day when it first came out, and then I continue to add to it now. And then, yeah, it's grown loads, I think about 2.8 million people or impressions it's had so far. So people tend to love visual ways of learning, which I find...

Eric Johnson: Well, I think it also...I don't do the Zettelkasten stuff, whatever you're talking about that book is, but I'm interested in it. I was looking up on Google Zettelkasten, and I can't find it, but I will. But it's interesting to me...I learn...I'm visual as well. I learn by breaking and fixing, right? If I haven't broken it and fixed it, I don't understand it. But I also learn in very small chunks, right? I think sometimes we try to boil the ocean is a term we use at AWS a lot is we try, you know, do all this stuff or understand all this stuff. However, the EDA visuals are very minimal, they're exactly what you described, they're thoughts, right? They're small, let's encompass in this, learn this concept, kind of the blinders on, and then we move to the next one. And it's cool. And if I'm not mistaken, on this site, you also generate a PDF, is that correct?

Dave Boyne: That's right. Yeah. So what I was doing...going back on that quickly, but the whole point of the visuals. Yeah, it was exactly that is like, what can you learn in five minutes? So everyone's super busy all the time. We've got things to do. We've got products to build or whatever it might be. So what can you realistically learn in five minutes? And that's where I try and target the visuals, which is like, okay, here's event architectures, and I was at the top of the funnel and the more I dive deep into it, the more this funnel just opens, and it continues to open. But it's like, how do I compress this information with the experts? There are loads of smart people down here. How can you compress this and bring that back up the funnel so people can understand?

The great thing about the Zettelkasten method too is when you create these permanent notes, and you create the second brain, you link back to resources, where did you read that blog post six months ago or three months ago? Why does this link to cloud events now or yesterday? What are the interesting things? And then with the visuals, what I've done is, every visual has, like, about five or six different resource links, so people can go and dive deeper. But what you're saying about the PDF documents, so the next thing I decided to try and do, which is like, okay, how can we just package these visuals up into a PDF? So I was looking around online, but there's this awesome tool called Pandoc. Oh, well, I'm not sure I call it awesome, but it works. I call it Pandoc, which allows me to…

Recommended talk: Realtime Serverless Communication with Momento Topics • Allen Helton • GOTO 2023

Eric Johnson: Heavy backpedal, backpedal. There's an average tool called...

Dave Boyne: I've had lots of lots of kind of sleepless nights with that one. But with Pandoc, it's a tool that allows you to kind of create, like, I guess, books or PDFs, whatever it is. And I experimented with a visual once. And I kind of remember, I finally generated it, and I put it on this document. And I thought it kind of gave it an interesting kind of, what's the word, content generation, content to be consumed. So from a website to a PDF is completely different, I felt. And then what I put on the website too, which I'll share a link, is you can download all the visuals, there's, like, 60 of them offline, for free. So you know, if you're commuting on a train or whatever it might be, on a plane, you can just quickly look for a visual, and yeah. So they've been downloaded about 7,000 times, I think, at the moment.

Eric Johnson: Wow. And it updates as you add new ones, yeah.

Dave Boyne: That's right, yes. It's all automated. So I always had a new one, it runs my Pandoc script, and then it generates and uploads it into the cloud.

Eric Johnson: Are you saying it's event-driven?

Dave Boyne: Well, yeah. Exactly that. Yeah.

Eric Johnson: I love how you commit and then you back...Oh, yeah, yeah. Well, I mean, yeah. It's a yes or no question, Dave Boyne.

Dave Boyne: I guess it is, yeah. It could probably be more event-driven. There's a bit of manual stuff to be done. In theory, it's event-driven.

Understanding Bounded Contexts and Messages

Eric Johnson: Okay, got it. All right. Very cool. All right. So I wanna kind of jump into them. First of all, okay, we defined EDA, hopefully, well enough. I'm sure we could do better. But hopefully, we got it. I think mine was better, but whatever. So we're gonna go through this. And, by now, there should be a link, you'll see a link underneath on what we're talking about. And then we're gonna talk about some of these specific visuals. And then we'll show links and go through those. But what is your favorite one?

Dave Boyne: I knew you were going to ask this.

Eric Johnson: I did. Well, I hope you were prepared for that. I'd like an answer. They're all my children.

Dave Boyne: I know. I don't necessarily have a favorite one, but we can start with this one, which I think...

Eric Johnson: Later, I'm gonna ask you who your favorite child is. So be prepared for that as well.

Dave Boyne: I'm prepared for that one. It's you, Eric Johnson.

Eric Johnson: I'm ready for that one.

Dave Boyne: You should be able to see this. So this is kind of an early one that I did. It's mainly around...So, as I said, event-driven architecture is just a huge, huge concept. And if you're into domain-driven design, which I recommend looking at, it also maps very well to event-driven architectures. And something I was looking at last year that I found very interesting is, like, the differences between messages and bounded context. And that's where this visual comes in actually...

The name of the visual is called messages between bounded contexts.

Recommended talk: Accelerating Event-driven Architecture with Domain-driven Design • Brian Zambrano • GOTO 2023

Eric Johnson: Okay. So now I'm gonna stop you, okay? So I want you to do some definition for us. And you're limited on time to do this. So what is a bounded context, right? And then message, I think we understand, but kind of explain that idea. You probably were already gonna do that, but I wanted to talk for a moment.

Dave Boyne: Yeah, sure. So in domain-driven design terms, we kind of build our applications...Well, even outside this, think about your applications and the boundaries of these applications. For example, we have a fulfillment service, order service, payment service, all these different boundaries that exist, right? And if you map this to, like, team topologies, which I'm kind of exploring at the moment, is how do we structure our organization around these teams and around these boundaries that allow us to kind of innovate?

Eric Johnson: Hang on a second. Did you say team topologies?

Dave Boyne: Team topologies. Going back to the bounding context is about the boundary of your domain, right? It's about how we communicate when we look at event-driven architectures is how we can use events or messages to communicate between these boundaries. And it's something I was thinking about a lot last year, which is like, okay, well, we can use events to communicate, that's great. I can publish an event right here. And Eric is handling payments, and he can receive this event and he can orchestrate and do whatever he wants. But there's much more to it than that. And this one I quite like a lot, which is what I talked about in my reinvent talk last year. It's all about, like, the different patterns you can use, depending on, like, the levels of coupling, I guess.

Examples here, so there's a conformist pattern. So one thing I do, I wasn't aware of when I started building event architectures is by default, we're all conforming, we're all conformists. So if I send Eric Johnson a payment event, and Erici consumes this event in his step functions workflow, as an example, he is conforming to my schema and my standard. Okay, so we are decoupled by nature with the boxes if we were to draw them up, but we are now coupled between contract, right, between schema. And this can be good and it can be bad.

An example of it being bad is if I am exposing implementation details, as an example. So now you know about the orders, order underscore ID, order underscore, I don't know, fulfillment status, all these things, all these nuances, all these properties that you might not be aware of or want to know. And this is all about boundary context, all about the levels of communication. And what this visual shows here is the differences between the communication and patterns that we can use.

An example you can see here on the screen is, like, the conformist pattern would be Eric conforms and takes it as it is. Anti-corruption layer here would be Eric, rather than conforming and taking it, he transforms it into the domain model and language that he can understand. An example of this would be Eric getting a payment event, so from me for whatever reason, or sorry, an order event from me. Eric Johnson chooses to map this event into something he and his team can understand, right? So we now have the separation between these boundaries. And equally, or the open host services would go back to me, Eric Johnson would go back to me, and we agree on a standard.

So these are very, like, small...what I'm getting at, while, like, this one's very small details, but they can make a big impact on how you build your event architectures. And I liked diving into this last year. There are some great resources on this page for you to dive deeper. But again, this for me comes back to us to teach, and I do teach event architecture. It's like, you need to think about some of this stuff.

Eric Johnson: To be honest, I hadn't heard of these. Now, I've looked at your visual stuff. Maybe I haven't studied this one enough. But that's interesting. So as I do, I'm gonna take it to an Eric Johnson level, meaning I'm going to dumb it down a little bit. Okay. So we say, like, conformist pattern, I take the event as it is, and I'm gonna oversimplify and frustrate you. I already know that. And then, like, anti-corruption layer. I change that incoming event to match what I need. So there's a transformation of the event. Okay. So all right. So I am getting this.

Dave Boyne: Exactly right. I'll give you an example, another example, literally today, I'm working service office hours, you probably see this back on repeat I'm doing a Kafka and event bridge integration on service office hours. So we will share a link with that. But an example here would be we got this Kafka stream connected to an event broker, which is an event bridge for us. And I'm consuming the Kafka stream of my partner, who was the on-prem engineer here. And I'm using something like input transformers with event bridge to map that into an event that I understand, that I want. So I'm no longer dealing with Kafka implementation details within step functions or my service. I've just pushed that outside the boundary of my service. So now I can talk about the domain language, which is orders, which is payments, which is a language in which we understand as an organization. I'm not talking about Kafka properties. I'm not talking about all these things.

Eric Johnson: Okay. So that's more than just remapping. Well, I guess when I first was thinking about it, it's like, you know, maybe injecting more data, but it could be remapping the data, renaming the...I mean, the data itself may stay the same, but the keys might change to a language you understand, do I understand that correctly?

Dave Boyne: Yeah, I think so. Yeah. And I think both of them are valuable, which is like, we can map the data into something we know. That's fair enough. What happens if we need to get more information? You just said it there, right? That's something completely different. So what people tend to do, again, I think I have visuals on this, which is you can go back to the producer, you can go back to an API and request that information. But now you have to understand that you are now coupled again. You know, we decoupled, I send you an event, and I send you a notification event. And Eric says, "Thank you very much. I need more information. Where can I get this?" You go back and ask me where the information is, and you get it for an API. But now again, we're coupled through that contract. So there are patterns, and there are other things to explore here about enrichment patterns, so we can enrich the event before Eric gets it. But as I said, you know, once we open this can of worms, we can keep going. And I'm not sure...yeah.

Event Design and Delivery Considerations

Eric Johnson: Maybe it's in the same vein. Maybe you have a pattern for this or visual in...When you're creating the original event, and we talk about this a lot, you know, sparse events versus, you know, full events, do you have a visual that addresses that?

Dave Boyne: Yes.

Eric Johnson: Of course, I do.

Dave Boyne: So here's one I have. I'll share it with you. So the visual is called "Why event design is important." And this one mainly talks about event design. But I have a talk I did for GOTO, again, we'll share the links here around event design, about 45 minutes of it. But the key is to understand the tradeoffs between the choices that we're making, ri. this is an interesting thing I see, I don't see a lot of people doing is treating event design as a first-class citizen. And what I mean by this is you often see people when we build APIs that we nurture APIs, we discuss APIs, we talk about APIs, we document APIs, all this stuff, we don't just one day wake up. And if we're building APIs between teams, you know, just implement it, there's a lot of thought and process because APIs have been around for decades, and events have also been around for decades. However, I think event-driven architecture is becoming more accessible to us.

But the problem with event architectures is often they jump into the event without thinking about its design because sometimes it's easy to do that. An example would be Eric Johnson, he needs to know about an order that has been created. So he tells the order service, and the order service says, "Okay. Well, that's fine. That's easy for me. I'll use a broker." Again, I'll use Event Bridge as an example, set it up straightforwardly, and I can publish a message on a managed event bus. Now, you know, Eric hasn't asked me about the fields. We've not discussed the fields. We've not discussed implementation details. We've not discussed the design itself. We've not discussed if it's gonna be minimal information. Is it gonna be big and sparse, which is like an event, carriage, or data transfer? There are always different terminologies. And what tends to happen if you dive in first is, you know, you'll get something, you'll say, "Thank you very much." In a week or two weeks, or two days, or two years, you'll come back and say, "This isn't what I need, we need to go bigger and bigger and bigger." And then we have breaking changes, we have versioning problems, we have all these things.

So that's why I'm saying event design, event-first thinking is super important. And when you start there, and this visual can help you, is talking about, are we gonna use notification events? Are we gonna use event carriage or state transfer events? Are we going to use delta events? There are even time series events, as an example. So think about the domain, think about the language we're talking about. As I mentioned earlier, does Eric need to know about order implementation details? Probably not. What does Eric need to know about? He needs to know about the order language as a business. So when your product owner or your product manager is talking to Eric about, what we need to implement this particular thing, what is an order? An order is something that a customer has placed. What's inside of an order? An order is this, is this, is this. We need to represent that in our models. We need to represent that in our events. So there are tons, as I said, you can keep going with this, but it's very important. The one takeaway here is just thinking about your event design can help you as you build EDA.

Recommended talk: Journey to EDA: Patterns, Best Practices & Practical Tips • David Boyne • GOTO 2023

Eric Johnson: So I'm gonna sort of push back, but I like the API conversation. And I'm gonna warn you, the next question I'm going to ask you because we've got 10 minutes left about. After all, I know we can go for years on this, but I wanna know the most complex pattern you have or the visual you have, and why was it complex for you to come up with. And while you're grabbing that...Yeah, I'm just throwing things at Dave Boyne. I'm trying to think of something hard. So I would like it alphabetized and no, I'm just kidding. It's interesting to me that you write...The whole conversation around APIs, If I'm building an API contract, if I'm doing it right if I don't get the right data, I reject the call, right? That's not the contract, therefore I don't do it. So A and B or Eric and Dave both must agree on what's coming in, what's being sent, what I'll accept, and stuff like that.

Whereas this is interesting, you know, it's a change in the mindset with event-driven architecture is Dave's kicking out events and he doesn't know who's consuming them a lot of the time. And so a lot of this is kind of done...and, you know, that's by design. This gives us the ability to build these massively distributed applications because now I do not have to do a contract with everybody who wants to talk to me. Now I'm just kicking out an event and saying, here it is. But you're right, that event is not...what happens is as more and more people come back and go, "You know what, I need this, and I need this, and I need this." Your event has gone from the sparse little fast thing, easy to process, to this cumbersome, bloated, double, you know, event. I agree that the planning of events is huge and critical.

Dave Boyne: I think that's a very interesting thing you said there is that we don't know who the consumers...We don't know who the consumers are And that's true, what tends to happen with event architectures easily is this idea of the big ball of mud, but you don't know who's consuming what, meaning we don't know how to change things. But what recommendation I would have there is thinking about the level of coupling between the systems. And what I mean by this is you can use brokers, we can use channels to communicate messages and events within a boundary, within a system. An example of this is if I was the order service and we wanted to use SNS, we want to use Event Bridge, whatever it is, or Kafka within our system ourselves, how we can change these contracts and communicate these changes is a lot easier than if it was an integration between teams in the organization. And then even beyond that, if I was publishing events to cross-organization, right, these contracts are completely different, then you have no idea who's consuming you, right? So there are different levels of governance and management that you need to do, depending on how, I guess, the events are consumed, too.

Eric Johnson: And here's the deal, Dave. This is not in your visuals, but I'd like it to be created as a visual. If you get that wrong, then there's a lot of team topologies.

Dave Boyne: Yeah, plenty of team topologies.

Understanding Event Failures

Eric Johnson: Team Topologies. Exactly. That's right. So I would like that to be Eric Johnson said that first. So there you go. Okay. So we have this last one, understanding event delivery failures. 

Dave Boyne: So just figuring out what happens when your events fail to be delivered, right? If we code for a happy path, that's fine. But what about if your event gets replayed? What happens if Eric Johnson processes the payment twice? We can't have that, right? So one way we handle that is through item consumers. Have we processed this before? Have we looked at this before? This is something we need to think about, which I recommend people think about, how do you design that architecture with these thoughts up front? What happens if the event fails to get delivered? Do you capture it or do you let it drop on the floor? What happens if you just let them drop? Is that a problem or should we capture them in the dead letter queue? Should we reprocess and replay them? Should we drive them?

And every broker out there has different retry policies and all sorts of things. So if you're using a broker, it's worth just diving into its documentation, understanding these nuances, understanding the retries, the failures, what can be configured, what can't be configured. And when you're building your event architectures and your systems, just ask yourself that question of, okay, that's fine, Eric Johnson, thank you very much. What happens if I don't send this event? What happens if you fail to receive this? What happens if...you know, and Eric Johnson, I know you've done lots on idempotency before in your talks, but yeah, how do you handle the idempotency stuff?

Eric Johnson: At Amazon, when we talk about services, we talk about order, this is guaranteed order, or we talk about at least once delivery, and that's a real critical thing when you're talking about...I do a whole talk on idempotency and how do you...before you...I mean, you know, I go through the database and look for duplicates. Well, if you're doing that, it's probably too late, right? So we've processed the payment twice that my mom has called me and freaked me out, right? But yeah, understanding the...and it comes down to cost, right? What is the cost if we charge someone twice? Well, there's credibility, there's, you know, the hassle of recovering that, there's different things like that. What is the cost if we don't take the payment at all and we go back to the customer and say, "Hey, there was an error, can we run this again?" Well, there's still some credibility, but there's...you know, so there's a balance there. And that's just obviously one of millions and millions of examples.

Like every good technical conversation, the answer is it depends, it depends on, what is important. What is the cost factor? What can you afford to let drop? What can you not afford to let drop? A lot of conversations around that. So, all right, I'm gonna have to stop us because Dave Boyne is a runaway train, he'll keep just going. But in just a minute, I'm gonna have you do a shameless plug, Dave, if you have anything you want to throw out there. But if you haven't checked out the visuals, I encourage you to, we've got the link to them all. Dave, how many are there?

Dave Boyne: I think it's about 60.

Eric Johnson: That's pretty good. And then there'll be 61 after we add the team topologies one that I do wanna see on there. So, 61, there you go. And so, I encourage you, if you struggle with EDA, if you're trying to learn EDA, this is a great place to look. If you're not looking at EDA, then you need to look at this. And you need to come visit us on EDA Day. Again, a shameless plug there. But EDA, the abilities...and this is interesting when we talk about interchangeability with service. AWS didn't invent EDA. We certainly didn't. EDA has been around since, I think, the '80s. 

Dave Boyne: Decades. 

Eric Johnson: Exactly. Yeah. But it's hard, right? Event-driven architecture is hard, but the wins you get out of it, you know, the robustness of your systems, you know, it's important. And with serverless, and I love the statement...and Dave Boyne, I wanna see if you agree with this. I've said it before, not all EDA is serverless, but all serverless is EDA. What do you think? Agree, disagree? He's running it through his head. There are probably some caveats there, but with serverless, we've made EDA very graspable. And so I encourage you to check that out. Dave Boyne, do you have anything you want to throw out before we have to wrap it up here?

Dave Boyne: Not a lot. No. There's some...On serverlessland.com, we have loads of guides around EDA stuff. The visuals live there. We have loads of videos that we...so we're on the serverless DA team at AWS. So if you check out some of our videos on YouTube, I did one last year on the journey to a venture in architecture. If you're just starting, or if you're on your journey, I cover lots of the stuff in the visuals and a talk and present it. So I recommend that. And equally, please reach out to me or Eric Johnson if you've got questions or, you know, if you enjoyed it or whatever else. Love to speak to you. And if you can come to the EDA Days that we do, fantastic. You know, let us know.

Eric Johnson: If you're in the London area, that'd be great to see you. We also wanna thank GOTO for letting us do this. We love GOTO. We love working with them. Dave Boyne: Cool. Cheers. All right.