Skip to main content

Event-Driven Architecture: Mediator vs Broker Topologies

What This Concept Is​

Event-driven architecture (EDA) uses events -- records of things that happened -- as the unit of inter-component communication. Components publish events; other components subscribe and react. There are two canonical topologies:

Broker topology​

No central coordinator. Events flow through a distributed message broker (Kafka, RabbitMQ, AWS SNS/SQS). Any service can publish; any service can subscribe. Coordination between services is choreographed: each service knows what events it emits and what events it consumes, and that is enough.

[service A] --publishes--> (broker topic X) --> [service B]
                                          \
                                           -> [service C]

[service B] --publishes--> (broker topic Y) --> [service D]
[service D] --publishes--> (broker topic Z) --> [service A, service C]

Mediator topology​

A central coordinator (an "event mediator" or "orchestrator") receives an initial event and directs the subsequent workflow. Services still communicate via events, but the sequencing is explicit in one place.

                     +---------------------+
                     |   Event Mediator    |
                     |   (orchestrator)    |
                     +----+-----+-----+----+
                          |     |     |
                          v     v     v
                     [A]  [B]  [C]  [D]

The mediator often holds state about a running workflow (modern implementations: AWS Step Functions, Camunda, Temporal, Netflix Conductor).

Comparison​

AxisBrokerMediator
SequencingChoreography: each service knows its partOrchestration: centralized
CouplingLow (services know topics only)Medium (mediator knows workflow)
VisibilityPoor (workflow is distributed)Good (one place to inspect)
Error handlingEach service handles its ownCentralized
EvolutionAdd a subscriber anytimeChange mediator to add a step
Failure modeLost events if broker failsSingle point of failure at mediator
Best fitReactive integration, pub/sub fan-outExplicit business workflows

Why It Matters Here​

EDA is the right default when:

  • the problem is inherently asynchronous (human workflows, background processing, multi-system coordination)
  • one "thing happens" and multiple systems need to react independently
  • you want loose coupling: adding a consumer should not require touching producers
  • throughput and elasticity matter more than request-response latency

EDA is the wrong default when:

  • the caller genuinely needs a synchronous answer ("is this card valid?")
  • your team has no operational capability for queue/broker infrastructure
  • the system is small and the overhead dwarfs the benefit
  • end-to-end tracing is a strict requirement and you have no observability budget

The choice between broker and mediator is the one most people get wrong. Broker is "cheap" at service-level and expensive at workflow-level (you cannot see what is happening); mediator is expensive at workflow-level and worth it when the workflow is business-critical and evolving.

Concrete Example​

Broker topology: order fulfillment with four services​

Customer clicks Buy
       |
       v
  [checkout] --publishes "OrderPlaced"--> (broker) --> [billing]    (charges card)
                                                  \
                                                   -> [inventory]   (reserves stock)
                                                    \
                                                     -> [notify]    (sends confirm email)

  [inventory] --publishes "StockReserved"--> (broker) --> [fulfillment] (picks & ships)

Observations:

  • no one coordinates. Each service knows its slice.
  • adding a fraud subscriber to OrderPlaced does not require touching checkout, billing, inventory, or notify.
  • nobody has the full picture in one place. A customer asking "where is my order?" requires correlating events across services.
  • a bug in billing does not directly fail the OrderPlaced publish, but it might cause notify to announce an order that was never charged. You need careful compensating-action design.

Mediator topology: same workflow under Temporal / Step Functions​

The workflow is visible in one place. Retries, compensations, and failures are explicit. The tradeoff: the mediator must be available; the workflow code is now coupled to the mediator framework.

Common Confusion / Misconception​

"Event-driven is the same as microservices." They are orthogonal. A modular monolith can use events internally (in-process event bus). A microservices system can be fully synchronous (REST only). Event-driven is about communication style; microservices is about deployment granularity.

"Broker topology is always better because it is more loosely coupled." Coupling to a mediator is more obvious and often easier to reason about than hidden coupling in a graph of choreographed subscribers. A broker system where 14 services subscribe to OrderPlaced and no one remembers what order they run in is not "loosely coupled"; it is obscured. Pick the topology by what the workflow is, not by which sounds better.

"Use broker for integration, mediator for business workflows." A useful rule of thumb, but not a law. Many real systems mix: brokers for reactive integration (logging, analytics, caching invalidation), mediators for important business processes (payment, onboarding, order fulfillment).

"Kafka = event-driven architecture." Kafka is a substrate; it does not make a system event-driven. A monolith that writes one Kafka topic and reads it back is still a monolith. EDA is about shifting the reasoning of the system to events-as-first-class-citizens.

"Events and messages are the same thing." Events describe something that happened (past tense, publisher-authored, multi-subscriber). Commands describe something that should happen (imperative, usually single-consumer). A broker can carry both, but treat them differently.

How To Use It​

Choosing EDA and topology:

Adoption preconditions (enforce these before you ship EDA):

  1. A schema registry or equivalent. Event schemas are contracts; evolving them breaks consumers. Use Avro/Protobuf with a registry, or document JSON schemas rigorously.
  2. Idempotency in consumers. At-least-once delivery is the default. Every consumer must handle duplicates.
  3. Dead-letter queues. Poison messages must not block the queue.
  4. Observability with correlation IDs. You cannot debug EDA by reading logs. Each event needs an ID that flows through every consumer; traces must stitch together.
  5. A retry and backoff policy. Document per-topic.
  6. A decision on ordering. Kafka offers partition-level ordering; SNS does not. Pick and defend.

Check Yourself​

  1. Name the single biggest disadvantage of broker topology in your own words. What tool or practice mitigates it?
  2. A team proposes moving their synchronous POST /orders to events. What three questions do you ask before agreeing?
  3. Why does "at-least-once delivery" imply "idempotent consumers"? What happens if consumers are not idempotent?

Mini Drill or Application​

Pick a workflow from a real system (checkout, onboarding, refund, deployment pipeline). In 25 minutes:

  1. Draw it as choreographed broker topology (events, topics, subscribers).
  2. Draw it as orchestrated mediator topology (mediator steps, branches).
  3. List two events where the broker version is better and two events where the mediator version is better.
  4. Pick one and defend it in three sentences.

Read This Only If Stuck​