Before You Publish Your First Event… Stop.

The hidden trap in event-driven architecture that few talk about

It’s 2025, and I’m more excited than ever about the possibilities of event-driven architecture (EDA). But at the same time, I’m worried…. The barrier to entry has become so low that it’s almost too easy to dive straight in.

Today, anyone can start building an event-driven system with just a single SDK call.

Thanks to the abundance of off-the-shelf services, you can define an event, publish it, and wire up a consumer in minutes.

And that’s exactly how most teams begin:

• Define an event

• Call the SDK

• Publish

• Connect a consumer

Over time, they’ll add in patterns like pub/sub, point-to-point, streaming, retries, and so on. But at the core, the mindset remains the same: implementation first.

I have learnt that this mindset eventually leads to complexity, chaos, and distributed mud (link to visual).

I’ve lost count of how many companies I’ve spoken to that hit this wall — and they all started with the same intentions….

But it doesn’t have to be this way.

If you’re just getting into event-driven architectures, my biggest piece of advice is this: don’t start with implementation. Start with behavior.

Ask yourself:

• What does this event really mean?

• How does it impact the system?

• Where does its boundary lie?

• How should it be designed and documented so it’s still clear six months from now?

We have incredible techniques at our disposal — EventStorming, EventModeling, domain-driven design practices (talk here) — that help us explore the problem space before a single line of code is written.

So before you reach for that SDK, pause. Explore your domain. Make the event design intentional. Capture its meaning and its boundaries.

A little thought upfront can save you countless hours of pain and refactoring later.

---

I’ve seen firsthand how quickly an “easy” start can spiral into architectural debt — but I’ve also seen how teams that invest in design early build systems that scale gracefully.

EDA is more powerful than ever. Just don’t let the simplicity of getting started fool you into skipping the hard — but essential — thinking.

---

I have some resources if you want to dive deeper, you can explore EDA visuals (free book with over 90 visuals to learn EDA, where I talk about these pitfalls).