Scalable Message Broker — A Contradiction in Terms?
If you read about the theoretical foundations behind the different methods to interconnect applications, you will no doubt hear challenges to a message broker’s ability to scale. These often come from articles written by Enterprise Service Bus vendors. This is most likely because use examples of non-scalable brokers to prove their point. We could do that too with almost any technology. Take a faulty implementation, make the assumption that its design is the only possible way to implement the technology, and then generalize as much as necessary to “prove” that the principle (theory) is flawed. Don’t worry — we won’t do that. Instead, we will consider the claim itself (“brokers are not scalable”) in more detail and see why its foundation is not sturdy.
The claim is that a message broker (such as ZIServer) cannot scale because:
- There is a single point of failure — a single database.
- There is a single point of failure — a web server or even multiple web servers in a single location.
- All data must be routed through a single location.
We took these claims into consideration, and created a superior message broker with 3 distinct features.
1. Multiple Databases
We intentionally split ZIServer’s data into multiple databases:
- A security information database: This is stored in a separate database for security reasons. The information is read from this database when ZIServer initially loads or starts a new process or processing thread.
- A working database: This contains configuration information and working information about currently active connections and messages waiting to be delivered.
- A database used to store archived audit messages: This database is partitioned into multiple sections depending on the age of the message, with each partition having its own separate database file.
Our larger ZIServer implementations use Microsoft SQL Server AlwaysOn Availability groups (and Distributed Availability Groups to keep real-time, up-to-date copies in different locations), plus we crisscross server roles so that different servers serve the “AlwaysOn Primary” role under normal operating conditions. Only after that do we use the scale-up capabilities that the authors of the aforementioned articles assume were the only features we had at our disposal.
We have matched ZIServer’s functionality with our Dexterity product to make sure that these databases are frequently backed up and are always “in tune.”
2. Multiple Web Servers
For both inbound and outbound messages, ZIServer supports load balancing using either hardware or Windows Network Load Balancing. These servers can be located in one or more locations if a customer needs to set up multiple locations for disaster recovery purposes.
For most brokers, outbound messaging would be an issue because even the largest of our competitors send messages from a single location. ZIServer, however, multi-threads outbound messages from all servers in its cluster while preserving correct message order, allowing for automatic failover and recovery in case of failure even if the servers are geographically dispersed.
3. Multiple Locations (Network)
This issue typically has to do with protection against intruders. In our experience, it is helpful to have the servers in a single location for Denial of Service attack protection. However, we found that many intruders have found ways to avoid the type of detection typically found in most networking equipment, and they have generalized security software by adding intelligence into the messages with which they attack.
For this reason, we built “counter intelligence” into our ZIServer product that quickly analyzes incoming messages to determine if a DoS pattern is emerging. Since messages could be received by web servers in different places (if ZIServer was set up in a disaster recovery configuration), these servers “compare notes” when such a pattern emerges, even if they are in faraway locations. On seeing such an attack, ZIServer can take action to protect the environment from those streams without taking down the entire service.
For more information on ZIServer, see: ZIServer