Five mistakes teams make with event-driven architecture

Teams tend to reach for this after something has already gone wrong. These are the ones we run into repeatedly when we audit event-driven architecture.

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. If two people in the business would answer this differently, that gap is the actual problem.

Common failure modes

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Events decouple producers from consumers, which is the whole point
• Debugging gets harder the moment nothing is synchronous
• Never checking whether the fix actually worked

Start with one event, not with an event bus. This is the sort of thing that compounds, quietly, in both directions. Write the reasoning down alongside the decision, because the reasoning is what changes first.

Making it stick

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
• Start with one event, not with an event bus — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.