Event-driven architecture: the short, honest version

Event-driven architecture is a useful tool that has been over-prescribed by consultants and conference talks. It is the right call for a smaller fraction of systems than the literature suggests — and when it is wrong, it is wrong in expensive, slow-to-undo ways.

When events earn their complexity

Events shine when you have multiple consumers that need to react to the same business fact, when those consumers evolve at different rates, and when you can tolerate eventual consistency between them. Order placed, payment captured, user signed up — these are facts the rest of the business genuinely wants to subscribe to.

The other clear win is integration boundaries. An event bus between two systems with mismatched release cadences is a far better integration point than synchronous RPC.

When events are the wrong tool

Within a single service or a single team, an event bus is almost always overkill. Function calls and database transactions are simpler, cheaper, and easier to reason about. Reaching for events to "decouple" code that is already in the same repository often produces the opposite — a distributed monolith with hidden temporal coupling.

Three failure modes

The shared-database event bus. Producers and consumers all read and write the same tables under the guise of "domain events". You now have all the complexity of an event-driven system with none of the isolation benefits.

The event-as-RPC. Producers expect a response. Consumers are blocking. You have built a slow, unreliable RPC.

The event without a schema contract. Producers add and remove fields without coordination. Consumers break silently. Every incident is a forensic exercise in payload archaeology.

The minimum bar for getting it right

If you are going to do event-driven architecture, do it with a schema registry, with consumers that can replay from a position cursor, with idempotent handlers, and with observability that lets you trace an event across consumers. Anything less and you will pay the complexity tax without getting the benefits.

For most teams, the right answer is "a small number of important events between services, everything else synchronous". That is not as exciting as the conference talks, but it is what works.