Service Oriented Architecture, Microservices, API, Hub-and-spoke, Event-bus

The broker pattern connects clients with services via a special-purpose component that provides a uniform communication protocol. Communication takes the form of request/response. The goal is make development of clients and services independent (decoupling).

The metaphore is as follows: You go to a broker to buy a house. You don't want to need to know all about the housing business. You just tell the broker your maximum price and some other requirements, and he starts looking for you.

How does it work?

Services are registered with the broker. The client requests a specific service: they format their request in a specific format and send it to the broker. The broker then selects the service to process the request. The broker sends the service's response back to the client.

Broker architecture diagram


An architecture with standalone services is called a service oriented architecture (SOA). The broker in a SOA commonly takes the form of an Enterprise Service Bus (ESB). In a microservices architecture the broker is more lightweight and the services more fine-grained.

There may also be multiple brokers in an architecture. These will then need their own communication protocols.

The broker may handle all messages directly, or place them in a queue, to be processed as soon as possible, or at a specified time. This is a message broker


  • REST based API's
  • Message queues

When should you use it?

  • In a large organization many teams work on different services. They don't want to be dependent on other teams.
  • When you want to provide your services publicly

Common implementation techniques

  • (Web) API
  • Enterprise Service Bus (ESB)
  • Message queue


  • Setting up the broker, and agree on a communication protocol can be quite a bit of work, even when using standard software.
  • The overhead of passing the call to a service via a broker has a performance penalty