PodParley PodParley
PodParley PodParley
Log in

Broker Pattern - Send Requests To The Correct Worker

Episode 6 of the Develpreneur: Become a Better Developer and Entrepreneur podcast, hosted by Rob Broadhead, titled "Broker Pattern - Send Requests To The Correct Worker" was published on January 20, 2022 and runs 15 minutes.

January 20, 2022 ·15m · Develpreneur: Become a Better Developer and Entrepreneur

0:00 / 0:00

Episode Description

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.

Challenges

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.

Share this episode

Similar Episodes

No similar episodes found.

Similar Podcasts

No similar podcasts found.

URL copied to clipboard!