Before you invest in event-driven architecture

There is no clever trick in this one, just a handful of decisions worth making deliberately. Before you spend anything on event-driven architecture, it is worth confirming a few things are already true.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. If two people in the business would answer this differently, that gap is the actual problem.

Prerequisites

• You can describe the outcome you want in one sentence
• Someone owns it after the work is done
• Events decouple producers from consumers, which is the whole point
• You have a way to tell whether it worked

Warning signs

Debugging gets harder the moment nothing is synchronous. Where this goes wrong is almost never a lack of knowledge. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

Start with one event, not with an event bus. The reasoning matters more than the rule, because the rule has exceptions. Write the reasoning down alongside the decision, because the reasoning is what changes first.

How to tell if yours is fine

Most systems fail at the seams rather than inside any one component. Three things worth confirming about event-driven architecture before you move on:

• Someone can say what the current setup is without going to look
• Events decouple producers from consumers, which is the whole point — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.