EDA for the Rest of Us: A Guide for the Confused

Over the past couple of months I’ve been trying to figure out what it means to have an event-driven architecture (EDA)? If you read books on the topic like Event-Driven Microservices and Flow Architectures you’d think that unless you’re running Apache Flink and Kafka you’re somehow doing it wrong. Yet tons of organizations claim they’re doing EDA without touching either of those tools. So what’s really going on here?

EDA is more than Messaging

We’ve been building systems with Message Queues and Enterprise Service Busses for decades, but EDA is more than just messaging. The difference isn’t in the infrastructure - it’s in how you think about and design your system interactions.

Traditional messaging? That’s when you have:

  • Services talking directly to each other because they have to
  • Request-response patterns where everything’s tightly coupled
  • Messages that are just technical plumbing, not business concepts
  • Async messaging thrown in as an afterthought when things get slow

Event-driven architecture is more about:

  • Your events actually mean something to the business, not just your code
  • Services that react to things happening instead of being told what to do
  • Producers and consumers that don’t need to know each other exist
  • Events that represent real business facts - “CustomerPurchasedItem” not “SendMessageToQueue”

The Real Questions

Look, this whole thing brings up some questions that nobody seems to want to talk about:

  • Does tooling define the approach? Like, if I’m using EventBridge and SQS, am I doing “real” EDA or just playing pretend until I graduate to Kafka?
  • What even IS an event? Seriously, when does my payment notification stop being just another JSON blob and become this mystical “business event”?
  • How much is enough? If most of my services still talk REST and only 20% use events, can I put EDA on my resume?

The Confusion is Real

A lot of what we call “EDA” has grown out of “message-driven” roots. We speak about things in an inconsistent manner across our systems. Some teams publish to SNS topics, others send messages through SQS queues, and a few are experimenting with EventBridge. We call it “event-driven,” but honestly, it feels more like “message-driven with extra steps.”

The gap between EDA theory and practice is frustrating. Academic resources assume you want to build Netflix-scale streaming platforms, while most of us just want services that don’t fall over when one team deploys on Friday afternoon.

What This Series Covers

So instead of arguing about whether we’re doing “real” EDA, I’m going to focus on patterns that actually work for building resilient, scalable systems using events effectively. Here’s what I’m going to cover:

  • Event Design Patterns: How to design events that represent business value rather than technical noise, when to use Event Notification vs Event Carried State Transfer, and why Event Sourcing isn’t always the answer.
  • Communication Patterns: The four fundamental ways events flow through your system - Publish-Subscribe, Point-to-Point, Request-Reply, and Event Streaming. Practical frameworks for choosing patterns based on your needs, AWS implementation options, and common anti-patterns that create architectural debt.
  • Consumption Patterns: Scaling event processing without complex infrastructure, filtering events effectively, and handling backpressure without distributed systems expertise.
  • Operational Challenges: Managing event schemas without breaking existing consumers, building event catalogs that people actually use, establishing ownership patterns that scale, monitoring event flows, debugging distributed event processing, and implementing replay capabilities for testing and recovery.

Let’s Get Going: EDA Doesn’t Need to Be Complicated

Whether you call it event-driven architecture, message-driven design, or “that thing where services talk to each other without everything exploding,” the point is the same: we want systems that don’t make us cry at 3 AM.

By the end of this series, you’ll have practical patterns you can use Monday morning - no distributed systems PhD required.

Let’s start with the basics: designing events that actually matter to your business.