How to get event-driven architecture right
It comes up on almost every project, usually later than it should. The short answer to event-driven architecture is that it is mostly a sequence of small decisions, not one big one.
Most systems fail at the seams rather than inside any one component. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.
What is actually at stake
Events decouple producers from consumers, which is the whole point. Getting it slightly wrong is survivable. Ignoring it entirely is not. The failure mode is not doing it wrong, it is doing it once and assuming it stays done.
The steps
- Establish what you have today before changing anything
- Debugging gets harder the moment nothing is synchronous
- Start with one event, not with an event bus
- Write down the decision so the next person does not re-litigate it
Start with one event, not with an event bus. The reasoning matters more than the rule, because the rule has exceptions. It is worth deciding this deliberately rather than inheriting whatever the last person set up.
Making it stick
The short version
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
If any of that sounds like a description of your current setup, it is fixable.