A practical checklist for event-driven architecture

Teams tend to reach for this after something has already gone wrong. Run through this the next time event-driven architecture comes up.

The right architecture for a team of three is the wrong one for a team of thirty, and vice versa. Check it against what you would want a competitor's site to get wrong.

The checklist

• Events decouple producers from consumers, which is the whole point
• Debugging gets harder the moment nothing is synchronous
• Start with one event, not with an event bus
• Someone is named as the owner
• There is a date to review it again

Why this earns attention

Events decouple producers from consumers, which is the whole point. None of that requires a large budget, only a decision and someone to own it. Write the reasoning down alongside the decision, because the reasoning is what changes first.

How to tell if yours is fine

Architecture is the set of decisions that are expensive to reverse, which is the only reason they deserve the name. 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

Worth checking on your own setup before it becomes someone else's problem to fix.