In event-driven architecture, what is the difference between a broker topology, where a checkout event triggers inventory, shipping, and notification services directly, versus a mediator topology, where a central component orchestrates the same steps? What do you give up by choosing the broker approach?

## The two topologies In broker topology, the network of participants is flat: there is no central controller. An event is placed onto a shared channel (a bus, topic, or similar distribution point), and every interested service subscribes and reacts on its own; if a reaction itself produces further events, those too get broadcast without any single component knowing the full sequence of what happened as a result of the original fact. In mediator topology, one component — the **mediator** or **orchestrator** — is itself a specialized consumer of the 'start' event, and it holds the recipe for the entire process: 1. it invokes each participating service in turn (typically via command-style events or direct calls), 2. waits for or listens to the corresponding completion signal, 3. and only then proceeds to the next step, tracking exactly where a given business instance currently is in the workflow. ## Which problem each one solves - **Broker topology suits reactive fan-out** where steps are genuinely independent — many services each doing their own unrelated thing in response to one fact, with no dependency on each other's outcome. - **Mediator topology exists to solve multi-step processes** with sequencing, branching, or error-handling/compensation requirements, which broker topology struggles with because coordination logic gets smeared across every participant: each service somehow has to know 'did the step before me succeed' without any central source of truth, leading to duplicated or implicit workflow knowledge scattered across services that were supposed to be independent. ## The trade-offs The trade-offs run in opposite directions. | Topology | What it buys, and what it charges | |---|---| | **Broker** | Broker topology offers high scalability and parallelism with minimal coupling, and it's trivial to add new reactors; the cost is no central visibility, difficulty enforcing ordering or conditional flows, and diagnosing 'why didn't X happen' requires tracing across N independently-owned services. | | **Mediator** | Mediator topology centralizes workflow logic in one testable, observable place, makes it easy to add new steps by changing the orchestrator, and supports compensation-style logic cleanly; the cost is that the mediator becomes a single point of coupling and a potential bottleneck, participants must be directly known to and reachable by the mediator (less decoupled than pure broker), and the mediator risks becoming an overloaded 'god component' if too many workflows accumulate inside it. | ## Failure modes in production In production, broker topology's characteristic failure is **invisible partial completion**: - 'did all four reactors run for this order?' is a question nobody can answer without extra tracking, - a slow or broken reactor blocks nothing else but silently leaves state inconsistent, - and adding a new *required* (not merely optional) reactor to an existing flow is dangerous because nothing enforces its execution. Mediator topology's characteristic failures are different: - the mediator becomes a scaling bottleneck as flow volume grows, - a mediator crash mid-workflow leaves business processes in an ambiguous state unless the mediator persists its own progress, - and because the mediator concentrates all business-process knowledge, a single change to it risks many workflows at once, growing its test surface disproportionately. ## Worked examples - **A broker-topology example**: an e-commerce `OrderPlaced` event is broadcast, and separately-owned inventory-reservation, email-confirmation, and analytics-ingest services react in parallel with zero coordination need, since none depends on another's outcome. - **A mediator-topology example**: a loan-approval process where identity verification must complete before a credit check, which must complete before final approval, and a rejection at any step must trigger a compensating notification and unwind reserved funds — the strict ordering and compensation requirements push this toward an explicit orchestrator that sequences each step and knows what to undo on failure, rather than leaving that logic implicit across independent reactors.