Overview
Broker and mediator topology are the two core styles for structuring event-driven architectures, differing in who controls the flow of events between components. In a broker topology, events flow directly between producers and consumers through a distributed broker with no central authority, while a mediator topology routes every event through a central orchestrator that dictates the sequence of steps. The choice determines how easily the system scales versus how easily complex, stateful workflows can be managed and debugged.
Comparison Diagram
Comparison Table
| Aspect | Broker Topology | Mediator Topology |
|---|---|---|
| Event entry point | Producer publishes to a broker/topic; consumers subscribe independently | Producer sends the event directly to a central mediator component |
| Control flow ownership | No single owner - flow emerges from a chain of independent subscriptions | Mediator explicitly owns and dictates the order of processing steps |
| Component coupling | Producers and consumers are decoupled from each other and from any workflow logic | Processors are decoupled from each other but coupled to the mediator’s contract |
| Workflow complexity support | Best suited to simple, single-step or loosely chained reactions | Built for complex, multi-step, conditional, or branching workflows |
| State and error management | Distributed across consumers, making end-to-end tracing harder | Centralized in the mediator, giving one place to track state and errors |
| Scalability | Scales horizontally with ease - add brokers or consumers freely | Mediator throughput can become a bottleneck as load grows |
| Failure impact | Broker or consumer outage only degrades that specific processing path | Mediator outage halts the entire orchestrated workflow |
| Adding or changing steps | Add a new consumer subscribing to an existing topic - no other code changes | Requires modifying the mediator’s orchestration logic directly |
Key Differences
- Control is implicit and distributed in broker topology versus explicit and centralized in mediator topology
- Broker topology favors scalability, while mediator topology favors workflow visibility
- Error handling is scattered across consumers in broker topology but consolidated in the mediator
- The mediator itself is a potential single point of failure, a risk broker topology avoids by design
- Changing a workflow means adding a subscriber in broker topology, but editing orchestration logic in mediator topology
When to Use Each
Broker Topology
- High-Volume Pub/Sub: Broker topology scales horizontally with minimal coordination overhead, ideal for high-throughput event streams.
- Independent Microservices: Services that react to events without needing awareness of a larger workflow fit naturally into a decentralized broker model.
- Simple Reactive Chains: When one event triggers a small number of loosely related follow-up actions, a broker avoids unnecessary orchestration overhead.
Mediator Topology
- Multi-Step Business Processes: Mediator topology suits workflows with strict ordering, branching, or compensation logic, like order fulfillment or approval chains.
- Centralized Error Recovery: When failures need coordinated retries or rollback across multiple steps, a mediator provides the single control point to manage that.
- Auditable Orchestration: Regulated processes that require a clear, traceable record of execution order benefit from the mediator’s explicit control flow.