Bus vs Broker

27 Mar

One of the easily confused concepts of messaging systems is the distinction between a bus and a broker. Some of the explanations you find on the web only confuse the matter, and the current trend of vendors marketing broker products as ESB’s only muddy the waters even more.

Message Broker

Message brokers are a centralized message router. This allows the origin of the message to be decoupled from the destination. A message is published to the broker, the broker then routes the message to the appropriate destination(s). The publisher of an event has no knowledge of the  subscriber of the event (not always a good thing, we’ll cover that later). As you may expect, the usual concerns associated with centralized architectures apply (single point of failure, difficult to scale out etc). These concerns can be addressed to some degree using standard scaling techniques for centralized architectures (e.g. clustering, sharding).

Message Bus

A message bus is a decentralized architecture. As such, it does not suffer the scalability and point-of-failure problems that you face with a broker. In a well designed system, this allows services to operate in a truly autonomous matter (a goal anyone building reliable distributed systems should strive for). Since there is no message router, publishers require prior knowledge of the destination(s) of the message(s). This also allows finer control over who can subscribe to each message, and which publisher(s) are the source of truth – not that big a deal in 90% of situations. The biggest advantage I see using a bus over a broker, is the decoupled applications. It is less work to scale out with a bus. In a bus environment you should be able to ‘spin up’ services with little to no effort while maintaining the tenets you strive for in a SOA. This means being able to scale out without any administrative hassles such as (re)configuring clusters and importantly, no unnecessary resource overhead that impacts performance. Remember the fallacies of distributed computing? Clustering introduces overheads (communication, I/O, cpu…), which, if you’re in a position where scaling out is a concern, you’re in a position where minimizing resource utilization is a priority. In my experience, a bus also allows you to build a solution without concerns of your infrastructure leaking into your code. This allows for a more supple design, some of which will we cover in my next post.

As with all things, the end result is only as good as the effort put into it. It’s very easy to design a bus architecture that won’t scale or operate autonomously if you don’t set these goals in the beginning. Likewise, you can build a brokered architecture that scales to your needs. A bus just allows you to scale beyond easier.

3 Responses to “Bus vs Broker”

  1. Liam March 28, 2013 at 4:11 pm #

    ahem http://www.eaipatterns.com/MessageBus.html

  2. Phillip Haydon (@philliphaydon) March 28, 2013 at 5:53 pm #

    @Liam – I don’t understand the point of your comment… what are you trying to prove with the link which isn’t already described above?

  3. Alphadogg August 29, 2013 at 12:26 pm #

    The above is theoretically incorrect, as far as I know. Brokering is the process of mapping and transforming messages between endpoints, as necessary. A message bus contains, in part, brokering functionality, but also routing (ex: pub/sub), queuing, policies and rules, etc.


    However, that is theory. As we know, industry mangles theory then complains about ivory towers insisting on their fancy definitions. :) But, in practice, most self-titled message brokers out there are really various degrees of message buses.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




Get every new post delivered to your Inbox.

%d bloggers like this: