Dynamic Message Routing

The underlying technology for an event mesh is Dynamic Message Routing (DMR). As your enterprise grows, you may find that your individual event brokers and event broker services (or nodes) are not sufficient to handle the demands of your business. At some point even the largest, most generously provisioned node has its limits, but these can be overcome by networking several nodes together and spreading the load among the participants. In this way, multiple nodes can be connected together to service loads far in excess of that possible by a single one.

Enterprise applications also become distributed across multiple sites—which can include multiple public and private clouds as well as legacy data centers—driving the need for an easy way to intelligently share information between all these locations and interfaces. For example, your organization may have on-premises applications using event brokers and event broker services that need to connect to cloud services such as AWS Lambda, Azure Event Hubs, or Google Functions.

Dynamic Message Routing (DMR) is a mechanism that allows connected nodes to automatically determine how to forward event messages. You use DMR to create a network, or event mesh, that connects individual brokers together within the same site (horizontal scaling) or between sites (multi-site scaling) to exchange subscription information. With an event mesh, clients don't need to know about other sites in the network. Once the relationships between event brokers and event broker services are established by the administrator, the event brokers dynamically discover how to route messages. Client applications don't have to take any special action to publish or consume messages across the mesh. They simply go about their business of exchanging messages without considering how to get those messages where they need to go. With DMR, you can move any applications within the mesh, or change the interests of those applications, and the mesh automatically updates the routing—without any intervention.

DMR supports two basic use cases: horizontal scaling and multi-site scaling. More complicated topologies are possible. If the use cases discussed here don't address your needs, contact Solace for assistance with designing and implementing your DMR mesh.

Horizontal Scaling

For horizontal scaling, you connect brokers together to create a DMR cluster. Each node (event broker or event broker service) in the cluster has a connection to every other node. These connections within the same cluster are called internal links; collectively, we refer to this as a "full mesh" of links. Within this fully-meshed cluster, each node is aware of all the others so that every event published in the network is seamlessly routed to the consuming applications.

DMR clusters are typically used for software and hardware event brokers at the same site. PubSub+ Cloud event broker services are usually set up as single-node cluster and don't use horizontal scaling.

Illustration depicting the concepts described in the surrounding text.

For more details, see DMR Subscription Propagation and Data Forwarding and the Horizontal Scaling example.

Multi-Site Scaling

In multi-site scaling, you connect two or more clusters together. Connections between clusters are called external links. Each cluster is connected together via a gateway node in each cluster. It is not necessary for each cluster to be connected to every other cluster; however, messages only propagate between directly-connected clusters. For example, if an external link was not configured between two cluster, messages do not pass between them. As shown in the diagram below, messages won't pass between Cluster A and Cluster C because they are not connected.

Illustration depicting the concepts described in the surrounding text.

For more details, see DMR Subscription Propagation and Data Forwarding and the Multi-Site Connectivity example.

Message Flow in an Event Mesh

Let's take a look at how DMR works in a scenario. The diagram below shows a horizontally-scaled cluster on-premises, which is connected to a DMR cluster in the public cloud (AWS in the example) and another cluster in a platform-as-a-service (PaaS) (Kubernetes in the example).

A publishing application (A) comes online and publishes to a topic, let's say tools/orders. A consuming application (B) in the same cluster comes online, binds to its queue, and subscribes to topic tools/orders. Events flow from application A to application B, preserving the quality of service (guaranteed or direct) of the publishing application A.

In addition, all subscriptions are shared between connected clusters. This means that event messages published by an application in one cluster are seamlessly routed to consuming application in other clusters.

In the example below, another consumer (C) comes online and subscribes to the same topic, tools/orders. Any event with topic tools/orders is now routed to the new consumer. As more publishers and consumers connect and disconnect, the routing is dynamically updated in the mesh.

DMR or a Message VPN Bridge?

DMR and VPN bridges are two alternate technologies that can be used to interconnect brokers. Both support guaranteed (persistent) and direct (non-persistent) messages. The advantage of DMR over VPN bridges is that with DMR you don’t need to statically configure topic subscriptions to define which events flow over the inter-broker links. DMR automatically routes your guaranteed and direct messages through your event mesh to all interested subscribers.

The PubSub+ Broker Manager includes a Click-to-Connect wizard that can easily create a DMR mesh in a few mouse clicks. Click-to-connect is also provided for VPN bridges, but you must then configure the topics that the bridges subscribe to.

When you want to strictly control which events go over an inter-broker link, you should use VPN bridges. When you want to build a large event mesh with minimal configuration effort and dynamic propagation of subscriptions throughout the mesh, DMR is the recommended choice.

Feature Interactions

Disaster Recovery (Replication)
You can take advantage of disaster recovery (using replication and Config-Sync) within your DMR network (or event mesh). Replication provides business continuity and allows mission‑critical applications to continue to function during a major service outage to a data center. For more information, see Data Center Replication for Disaster Recovery and Configuring Replication with a DMR Network.
Message VPN Bridging
Bridging and DMR are compatible, and can be used at the same time. However, we recommend that you don't configure VPN bridge links and DMR links between the same event brokers because this configuration causes duplicate message delivery.
Multi-Node Routing
Multi-Node Routing (MNR) and DMR cannot be used at the same time. They are mutually exclusive.

If you want to migrate from MNR to DMR, contact Solace for assistance.

Next Steps