The broker pattern may seem very similar to some others we have examined.  However, it is more about distributed systems than balancing traffic.  The pipe-filter and master-slave patterns provide single path processing.  This pattern sends the requests down different paths based on the request itself.

The Broker Pattern Defined

A broker pattern is a sort of tree structure.  We start with a client that makes a request to the broker.  The broker assesses that request and then sends it to a server that can handle the request.  Note that the selected server is not a candidate for load purposes as much as its services.  The broker queries servers (or server report when they register) for services provided.  This pattern allows us to have a flexible system for requests.

Stepwise Expansion of Services

The strength of a broker is that it can accept any request.  However, that does not mean it will process every request.  If there is no server that can handle the request, then an error or service not available response is sent.  That allows servers to go down and the broker to still take requests somehow, or we can add services to expand what the broker can do.
We can also version our services to expand individually while still supporting older requests.  For example, the request to get a customer record may go to different servers depending on whether it is a “1.0” customer record or a “2.0” record.  Clients will always be able to make requests and might even retry them to wait for a server to become available.


The broker pattern is sort of like a yes-man.  It will take any request and pass it on or say the service is not defined.  It is not going to tell you much more about the request.  A malformed request may never be supported while not flagged as such.  This pattern can create a massive backlog of enhancements because they can often be seen as easily tacked on.  There is a need to reign in the scope of new requests or at least to plan out the roadmap for them.  Otherwise, the broker may get flooded with requests for non-existent services that impact the performance of those it is meant to serve.

Rob Broadhead

Rob is a founder of, and frequent contributor to, Develpreneur. This includes the Building Better Developers podcast. He is also a longtime student of technology as a developer, designer, and manager of software solutions. Rob is a founder and principle of RB Consulting and has managed to author a book about his family experiences. In his free time, he stays busy raising five children (although a few have grown into adults). When he has a chance to breathe, he is on the ice playing hockey to relax.

Leave a Reply