The Architecture of the Event-Driven Architecture Pattern

Event-Driven Architecture (EDA) is a style in which components communicate by producing and reacting to events rather than calling each other directly. An event is an immutable record that something happened — MotionDetected, OrderPlaced, TemperatureChanged. The producer that emits it does not know, and does not care, who will consume it. That single fact — the decoupling of "something happened" from "what to do about it" — is the source of every benefit and every headache in EDA.

The moving parts

• Event producers — components that detect a state change and emit an event. A motion sensor that fires MotionDetected is a producer.
• Event channels / topics — named pipelines that carry events of a given type from producers toward whoever is interested.
• Event bus / broker — the transport that accepts events and delivers them to the right channels (Kafka, RabbitMQ, AWS EventBridge, a cloud pub/sub, or an in-process dispatcher).
• Event consumers — components that subscribe to channels and act on the events they receive, typically causing a further state change or emitting new events.

Two structural questions decide the shape of the whole system: who owns the routing and business decisions, and how tightly are producers coupled to consumers. Those questions produce two canonical topologies — Mediator and Broker — plus a Hybrid that mixes them.

Two topologies, one core trade-off

Mediator (orchestration)

A central mediator knows the producers and consumers and orchestrates the flow. Producers send events to the mediator; the mediator applies routing, filtering, transformation, and multi-step business logic, then dispatches commands to the appropriate consumers. The workflow lives in one place, so it is easy to read, reorder, and reason about.

Price: the mediator is a single point that every event flows through. It can become a throughput bottleneck and a scaling/availability chokepoint, and it accumulates coupling — as you add features, the mediator gets fatter.

Broker (choreography)

There is no central coordinator. Producers publish events directly to channels on the bus; consumers subscribe and react independently. The bus just moves events. This is highly scalable and evolvable — you can add a new consumer to an existing event stream without touching the producer or any other consumer.

Price: the business logic is now scattered across consumers. No single component knows the end-to-end flow, which makes a multi-step process harder to trace, debug, and change coherently.

Hybrid EDA uses a broker for high-volume ingestion and fan-out, and a mediator for the few workflows that genuinely need central orchestration — capturing most of the throughput of broker with the control of mediator where it matters.

Trace one event through both topologies

Take a concrete home-automation requirement: when the front-door motion sensor fires, turn on the porch light — but only at night. The interesting question is not "does the light turn on" but where the "only at night" decision lives. That is exactly what the topology decides.

Mediator: the decision is central

The night-check sits in one place. To later say "also only when nobody is home", you edit the mediator and nothing else.

Broker: the decision is at the edge

The night-check now lives inside the consumer. The upside: a new subscriber — say a security camera — can react to the very same MotionDetected stream without anyone changing the sensor or the light. The downside: if three consumers each need the night rule, that logic is now copied in three places, and no single component describes the whole behavior.

Choosing well: the selection layer

Mediator vs Broker

• Reach for Mediator when there is a real workflow — ordered, multi-step, needs transformation/aggregation, or must be auditable and changed as a unit (order fulfillment, payment orchestration, saga coordination). You are trading throughput and a single chokepoint for clarity and control.
• Reach for Broker when events are notifications that many independent parties react to, when throughput and independent scaling dominate, or when you expect to keep adding consumers over time (analytics, activity feeds, IoT telemetry fan-out). You are trading end-to-end visibility for scale and evolvability.
• Reach for Hybrid when most traffic is fire-and-forget fan-out but a handful of flows genuinely need orchestration — broker for the firehose, a mediator for those specific workflows.

EDA vs plain request/response

Don't default to events. Prefer synchronous request/response when the caller needs an immediate answer, when you want strong/read-your-write consistency, or when the interaction is a simple one-to-one call — an async event round-trip only adds latency and moving parts there. Prefer EDA when you want temporal decoupling (producer and consumer need not be up at the same time), fan-out to many/unknown consumers, resilience to consumer slowness via buffering, or the freedom to add reactions later without touching the source. A useful tell: if the producer needs the result to continue, that is a call; if it is simply announcing a fact, that is an event.

Pitfalls that bite in production

• Idempotency. Most brokers deliver at-least-once, so consumers will see duplicates. Make handlers idempotent — dedupe on a stable event ID, or design the effect so applying it twice is harmless ("set light on" is naturally idempotent; "increment counter" is not).
• Dead-letter handling. A poison event that always fails must not block the channel or loop forever. Route it to a dead-letter queue after N retries so the stream keeps flowing and the failure can be inspected.
• Correlation IDs. Because no single component owns the end-to-end flow (especially under Broker), stamp each event with a correlation ID and propagate it through every downstream event, so you can reconstruct one logical transaction across many async hops when debugging.
• Fat vs thin events. A thin event carries just an ID ("OrderPlaced #42") and forces consumers to call back for details — simple and small, but chatty and coupling. A fat event (event-carried state transfer) embeds the data consumers need, removing callbacks at the cost of larger payloads and stale-data risk. Choose deliberately per event; it is a real coupling and consistency decision, not a formatting detail.

Takeaways

• EDA decouples "what happened" from "what to do about it." Producers emit facts; consumers react. That decoupling buys flexibility, temporal independence, and fan-out — and it is also the source of every operational complication below.
• The topology decides where your logic lives. The whole Mediator-vs-Broker choice comes down to one question: does the business decision sit in one central orchestrator, or is it distributed across the consumers at the edge?
• Pick Mediator when you need centralized control over an ordered, multi-step workflow — rich routing, transformation, auditability, and one place to change behavior — and you can accept that the mediator is a throughput bottleneck and a magnet for coupling.
• Pick Broker when you need scale and evolvability — no central chokepoint, and new consumers can join an existing event stream without touching anyone else — and you can accept that the flow logic is scattered and end-to-end tracing is harder.
• Pick Hybrid when the system is mostly high-volume fan-out with a few workflows that truly need orchestration: broker for the firehose, mediator for those flows.
• Don't reach for events at all when the caller needs an immediate answer or strong consistency — that is a synchronous request/response, and forcing it through a bus only adds latency and failure modes.
• Whatever you choose, engineer for the async reality: idempotent consumers, dead-letter queues, correlation IDs for tracing, and a deliberate fat-vs-thin event contract. These are not optional polish — they are what separates a demo from a system that survives duplicates, failures, and 3 a.m. debugging.

Source

Mediator and Broker EDA topologies and their trade-offs follow the canonical treatment in Mark Richards, Software Architecture Patterns (O'Reilly). The idempotency, dead-letter, correlation-ID, and event-carried-state-transfer (fat vs thin event) practices draw on Sam Newman, Building Microservices (2nd ed., O'Reilly), and Martin Fowler's writing on event-driven architectures. The home-automation MotionDetected walkthrough and step tables are original teaching material built on top of those sources.