What to ask your agency about event-driven architecture

Every audit we run turns up some version of this. If you are briefing an agency or a freelancer on event-driven architecture, these questions are worth asking early.

Most systems fail at the seams rather than inside any one component. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Questions worth asking

• Who will actually do this work, and have they done it before?
• How will we know afterwards whether it worked?
• What happens if it needs changing in a year?
• What are you assuming that we have not confirmed?

What a good answer sounds like

Events decouple producers from consumers, which is the whole point. The teams that handle this well are rarely the ones with the biggest budgets. Budget a little time for it every quarter and it never becomes a project of its own.

Start with one event, not with an event bus. None of that requires a large budget, only a decision and someone to own it. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

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

Pick the one that would hurt most if it failed, and start there.