Three myths about event-driven architecture

Most teams know this matters. Fewer have decided who owns it. A few things about event-driven architecture that get repeated more often than they get checked.

Most systems fail at the seams rather than inside any one component. The version that survives contact with a real deadline is the simple one.

“It only matters for big sites”

Events decouple producers from consumers, which is the whole point. The reasoning matters more than the rule, because the rule has exceptions. If two people in the business would answer this differently, that gap is the actual problem.

“We can deal with it after launch”

Sometimes true, usually expensive. There is a version of this that is over-engineered, and it is worth avoiding.

“Our platform handles it”

Start with one event, not with an event bus. It is worth being explicit about, because assumptions differ quietly. It is the sort of thing that looks like polish right up until it costs you an enquiry.

What this looks like day to day

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

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