# Broker Pattern

**In short:** The broker pattern organizes a distributed system around one central component. Decoupled parts interact through remote calls, and the broker coordinates them. It forwards requests and returns results and errors. The whole system depends on it.

## Explanation

A distributed system runs its parts on different machines or in different processes. In the broker pattern, these parts are decoupled. They do not talk to each other directly. They interact through remote calls, and a central component called the broker coordinates the communication.

The broker has a clear job. It forwards requests from one part to another. It transmits the results back. It also passes on exceptions (error reports) when a call fails.

A closely related idea exists in enterprise messaging. A Message Broker answers this question: how can you separate a message's destination from its sender, yet keep central control over the flow of messages? The broker receives each message, determines the correct destination, and routes the message to the right channel. The articles on Message Routing and Messaging give background.

A Messaging Bridge is a neighboring idea. It connects separate messaging systems by replicating messages between them.

Some people confuse the broker pattern with the Publish-Subscribe Pattern. The two have similarities, but they are represented differently. Treat them as separate patterns.

## Example

An order service needs a price from a pricing service. It does not know where the pricing service runs. It sends the request to the broker. The broker forwards the request and returns the price to the order service. If the call fails, the broker passes the error back instead.

## Trade-offs

- **Single point of dependence.** All communication runs through one central component. That component must be robust and efficiently written, because everything depends on it.
- **Bottleneck risk.** Routing all messages through a single broker can turn it into a serious bottleneck.
- **Benefit.** Senders do not need to know destinations, and the broker keeps central control over message flow.

A broker forwards a request and returns the result or exception.

```mermaid
flowchart LR
  C[Client] -->|request| B[Broker]
  B -->|forwarded request| S[Server]
  S -->|result or exception| B
  B -->|result or exception| C
```

## Checks

- The document names the broker component and states that it coordinates communication, forwards requests, and returns results and exceptions.
- The document explains how the broker's robustness and efficiency are ensured, since the system depends on it.
- The document assesses whether routing all messages through one broker creates a bottleneck.
- The document distinguishes the broker pattern from publish-subscribe where both are mentioned.

## Related

- [Publish-Subscribe Pattern](https://arc.fuet.ch/concepts/styles-patterns/publish-subscribe-pattern.md)
- [Message Routing](https://arc.fuet.ch/concepts/integration/message-routing.md)
- [Messaging](https://arc.fuet.ch/concepts/integration/messaging.md)
- [Remote Procedure Call](https://arc.fuet.ch/concepts/integration/remote-procedure-call.md)
- [Loose Coupling](https://arc.fuet.ch/concepts/principles/loose-coupling.md)
- [Architectural Pattern](https://arc.fuet.ch/concepts/styles-patterns/architectural-pattern.md)
- [Enterprise Integration Patterns](https://arc.fuet.ch/concepts/integration/messaging-pattern-language.md)
- [Connectors and Distribution](https://arc.fuet.ch/concepts/fundamentals/connectors-and-distribution.md)

## Sources

- [Broker pattern - Wikipedia](https://en.wikipedia.org/wiki/Broker_pattern) — en.wikipedia.org, accessed 2026-11-08
- [Message Broker - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessageBroker.html) — enterpriseintegrationpatterns.com, accessed 2026-11-08
- [Messaging Bridge - Enterprise Integration Patterns](https://www.enterpriseintegrationpatterns.com/patterns/messaging/MessagingBridge.html) — enterpriseintegrationpatterns.com, accessed 2026-11-08