Event-driven architecture, explained without the jargon

Teams tend to reach for this after something has already gone wrong. Here is event-driven architecture without the vocabulary that usually surrounds it.

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

The short version

Events decouple producers from consumers, which is the whole point. The cost of getting this wrong is rarely visible on the day it happens. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. Getting it slightly wrong is survivable. Ignoring it entirely is not.

Debugging gets harder the moment nothing is synchronous. The cost of getting this wrong is rarely visible on the day it happens. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Making it stick

Start with one event, not with an event bus. The teams that handle this well are rarely the ones with the biggest budgets. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

The short version

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Three things worth confirming about event-driven architecture before you move on:

• Someone can say what the current setup is without going to look
• Debugging gets harder the moment nothing is synchronous — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Most of the value here comes from doing the first two things, not all of them.