Getting started with event-driven architecture
The version of this that works is simpler than the version most people imagine. A short on-ramp to event-driven architecture for teams who have not touched it before.
Most systems fail at the seams rather than inside any one component. Write the reasoning down alongside the decision, because the reasoning is what changes first.
What it costs to ignore
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.
Your first week
- Find out what is already in place
- Debugging gets harder the moment nothing is synchronous
- Change one thing and measure it
Start with one event, not with an event bus. The teams that handle this well are rarely the ones with the biggest budgets. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
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 you are not sure where your systems currently stand on this, it takes us about an hour to find out.