Broker and Mediator Topology
Two ways of organising an event-driven system — components reacting independently to a shared channel, or a central component coordinating a defined sequence.
Broker topology: events are published to a channel and interested components react. No central coordinator, minimal coupling, high scalability — and no single place that knows what a business process does, which makes error handling, compensation and monitoring genuinely difficult. Determining why an order was not fulfilled means reconstructing behaviour across many components.
Mediator topology: a component owns the process, invoking steps and handling failures. The workflow is explicit, error handling and compensation live in one place, and progress is observable — at the cost of a component that knows about all the participants, and a bottleneck for change.
The productive way to choose is per process, not per system. Simple reactive flows suit a broker; business-critical processes with compensation, timeouts and visible state suit a mediator. Most real systems contain both.
This is the same distinction as choreography versus orchestration, and the trade is identical: coupling against comprehensibility. Teams routinely pick a broker for everything on decoupling grounds and then build an ad-hoc mediator out of database columns when they need to know what is happening.