Event-driven architecture: the questions we get asked most

It comes up on almost every project, usually later than it should. The questions about event-driven architecture that come up most often on our calls.

Most systems fail at the seams rather than inside any one component. Assume whoever inherits this will have half your context and none of your patience.

Do we need to care about this?

Events decouple producers from consumers, which is the whole point. It is worth being explicit about, because assumptions differ quietly. The version that survives contact with a real deadline is the simple one.

Can it wait until after launch?

Occasionally. More often the post-launch version costs several times the pre-launch one. None of that requires a large budget, only a decision and someone to own it.

How do we know it is working?

Start with one event, not with an event bus. There is a version of this that is over-engineered, and it is worth avoiding. Doing this properly once is usually cheaper than doing it approximately three times.

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.