EDA in the Wild: Patterns from 20+ Real-World Deployments


I've spent the last few weeks on over 20 calls with all kinds of companies. From tiny startups to huge enterprises. Every single one of them is wrestling with Event-Driven Architecture, trying to make sense of its promise and its messy reality. And as I listened, patterns started jumping out at me. We're not just talking about tech problems here. We're hitting the deep, human stuff that comes with a big shift like this.

One story kept popping up, louder than all the others: culture. Forget Kafka, RabbitMQ, or even AsyncAPI. The real mountain to climb was always the teams' ingrained habits and mindsets. Take a big retailer I spoke with. They're growing like crazy, but their teams kept falling back into unwanted data replication. It wasn't that they were bad at their jobs or doing it on purpose. It was this strong, inherited desire for autonomy. A need to control their own flow of work because they felt dependent on other teams. This just hammers home something I really believe: you have to understand the actual problem first, not just grab a new tool.

Synchronous systems give you that instant feedback, and that's powerful. But debugging an asynchronous flow? That can feel like trying to find your way through a hall of mirrors. This isn't just engineers learning new tricks. It demands serious patience from everyone as they adjust to a totally different rhythm.

Then there's the non-stop chase for governance. Companies that really nailed REST API governance are now trying to bring that same order to the wild west of events. They want discoverability, consistency, and everyone on the same page, like a perfectly cataloged library instead of a chaotic pile of unmarked books. AsyncAPI is a huge help here. It gives us a common language.

What's super clear is that effective governance isn't about top-down mandates (although they are pretty much necessary). It's about getting people to work together. It's about domains owning their events but also contributing to a shared understanding. It's a journey of growing together, slowly but surely shaping the chaos into something coherent.

And what about the events themselves? Most organizations are just dipping their toes into the async waters with notification events. These are small messages that just tell you something happened, without dumping a whole bunch of data into the payload. It's a smart first step because it lets them avoid the headaches of distributed transactions and eventual consistency for now.

This cautious approach usually means they end up with hybrid architectures. New EDA patterns live side-by-side with their synchronous APIs. It's messy, it's real-world, and it's definitely not those clean diagrams you see in textbooks. But that's how real progress happens. The ongoing debate about how much data to embed in an event versus just fetching it with an API call really shows you the constant balancing act between keeping things decoupled and making them efficient.

Underneath all these tech and organizational shifts is the absolute critical role of education and communication. It's not enough for engineers to get the ins and outs of event streams. Business leaders need to understand the strategic value. The "why" behind this whole shift. As one leader put it, "upskilling business people first" can totally align incentives and smooth the path. And for platform teams? Their role is changing big time. They're less of a "center of excellence" just issuing decrees. They're more like collaborative partners, "learning from application teams' experiences," helping everyone adopt this new way of working, and building shared understanding through genuine collaboration, not just mandates.

What these 20+ calls made absolutely clear is that adopting EDA isn't about following one perfect blueprint. It's about constant adaptation. It's about patience, about growing together as a team, and above all, about building a shared understanding as we navigate this exciting, often challenging, shift together.

P.S. Remember you can get early access to read Shift, at a discounted price. Get early access now.

P.P.S. If you're stuck, need a second pair of eyes on your architecture, or want personalized guidance to accelerate your project, a 1:1 call can provide the clarity and direction you need. Book Your 1:1 Consultation.

1 Question For You

I'm gauging the market to understand if there's interest about a video course of EDA and AsyncAPI. Would you be interested? Feel free to reply to this email to give me more details.

Av. Joaquín Costa, 16, Badajoz, Badajoz 06001
Unsubscribe · Preferences

Fran Méndez

Hey hey! I'm Fran, the creator of the AsyncAPI specification (the industry standard for defining asynchronous APIs). Subscribe to my newsletter —The Weekly Shift— where I share expert advice about building Event-Driven Architecture and share my journey writing my first book, Shift: The Playbook for Event-Driven Architecture Advocacy.

Read more from Fran Méndez

Writing Shift is proving to be challenging to me. Not in a bad way but in a really really good way. Yesterday, in a conversation with Laïla Bougriâ, I told her that I'm writing the book for me, to learn. Obviously, I'm taking into account the target audience all the time but, even this, is part of the challenge. It's not the first time I've done this though. When I drafted the first AsyncAPI specification, I did it for me, so I could learn the ins and outs of OpenAPI and also Event-Driven...

Addressing a culture problem with a tool is like taking a hammer to your own head. The more powerful the tool, the more painful the blow.

This week, I had an interesting discussion with a client. It's a Civil Engineering corporation that's present in multiple continents. The "company culture" challenge becomes especially important when different cultures all around the globe are mixed toward a same goal. Building a globally-distributed Event-Driven Architecture is no exception. Everywhere I look, people are trying to fix culture problems with tools. Not because they're dumb or stupid, actually, I'd have committed the same...

The biggest problem with Event-Driven Architecture

This week I want to share some interesting insights with you. For the last ~3 months, I've had video-calls with a lot of people from different companies in different markets. Mostly banks, retail, and consultants. I kept these calls informal, like casual chats. I didn't want to bias anyone toward any findings so I prepared myself to run "interviews". Have a look at The Mom Test. I asked open questions all the time and, from there, followed the conversations in a natural way. I tried not to...