Event-Driven Systems Without Folklore

Event-driven architecture helps when the system needs loose coupling, delayed work, or fan-out across multiple consumers. It hurts when teams use async as a default and lose sight of failure visibility, replay cost, and the operational burden of distributed behavior.

This is the useful question: not "is event-driven more modern?" but "does async reduce the total cost of this workflow?" If the answer is no, a synchronous design is often safer, cheaper, and easier to operate.

Martin Fowler's essay on what event-driven means is still a good framing reference because it separates the style from the hype. In production, though, the important question is not the pattern label. It is whether you can afford the recovery model that comes with it.

Event-driven systems react to facts that already happened: an order was paid, a user signed up, a record changed. Instead of forcing all follow-up work into one in-line request, the system publishes an event and lets downstream consumers decide what to do next.

That design shifts pressure from one place to another. You are no longer only designing behavior. You are also designing contracts, retries, idempotency, replay, and ownership.

The trade-off is not old versus new architecture. It is direct control versus delayed coupling.

Use sync when correctness depends on an immediate answer. Use async when the work can happen later without harming the business result.

Async is strongest when the business problem benefits from separation in time or ownership.

Typical cases:

• one action fans out into several independent reactions
• slow or unreliable downstream work should not block the user
• traffic is bursty and needs buffering
• the business benefits from a durable history of domain facts
• multiple teams need to evolve without tight request coupling

Examples:

• send a confirmation email after signup
• update analytics after checkout
• sync a search index after content changes
• trigger a fraud review after suspicious behavior

Async becomes expensive when the workflow needs:

• immediate correctness
• strict transactional boundaries
• low ambiguity about success or failure
• tight coordination across consumers anyway

If a payment or permission check must be authoritative in the moment, an event is often the wrong abstraction.

Event-driven systems can still be tightly coupled:

• a consumer depends on fields the producer may remove
• a schema change breaks older consumers
• a downstream service becomes the hidden owner of a business rule
• producers and consumers negotiate contracts informally every week

Loose coupling only exists when contracts are stable enough for each side to move independently.

An event bus is transport, not resolution. The hard questions remain:

• how do you know an event was not processed?
• how do you detect duplicate processing?
• how do you recover after a consumer outage?
• how do you know whether a consumer is stuck or simply slow?

Without answers to those questions, async is hiding risk instead of managing it.

Replay is one of the most underestimated costs in event-driven systems.

Replay cost shows up in:

• compute cost from reprocessing history
• coordination cost from deciding what to replay and when
• correctness cost when old logic interacts with new state

Replay should be an explicit capability, not a magical phrase used in architecture diagrams.

That same idea shows up in the idempotent consumer pattern: if replay and duplicate delivery are expected, the consumer contract must be designed for it rather than bolted on later.

Document:

• which events are replayable
• which consumers can safely re-run
• how duplicate side effects are prevented
• how to verify replay success

Sagas are useful when a business process spans multiple services and rollback must be explicit rather than transactional.

Use a saga when:

• the workflow is long-running
• each step has an independent side effect
• compensation must be modeled intentionally
• eventual completion is acceptable

Do not use a saga just because a transaction feels inconvenient. It is still a complex state machine with its own failure and recovery paths.

Chris Richardson's write-up of the Saga pattern is useful here because it makes the trade explicit: sagas maintain consistency across services, but they replace automatic rollback with compensating logic you now have to own.

Use this checklist before you choose event-driven architecture:

1. Does the caller need immediate success or failure?
2. Can downstream work happen later without harming correctness?
3. Is the workflow fan-out heavy enough to justify decoupling?
4. Can you observe lag, failure, and retries clearly?
5. Do you have idempotent consumers and a safe replay path?
6. Do event contracts have ownership and versioning rules?
7. Would a synchronous request be simpler and cheaper to operate?

If more than two answers are uncertain, the system is probably not ready for async.

• define events as business facts, not transport payloads
• assign clear schema ownership
• make consumers idempotent before you add retries
• track lag, dead-letter volume, and failure rate
• document replay and compensation procedures