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 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).
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.