When event-driven architecture is worth the effort

It comes up on almost every project, usually later than it should. Event-driven architecture is not free, and pretending otherwise leads to bad decisions.

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. Doing this properly once is usually cheaper than doing it approximately three times.

When it is worth it

Events decouple producers from consumers, which is the whole point. This is the sort of thing that compounds, quietly, in both directions. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. The teams that handle this well are rarely the ones with the biggest budgets.

How to decide

Start with one event, not with an event bus. It is worth being explicit about, because assumptions differ quietly. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

How to tell if yours is fine

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
• 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

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