Solace Event Mesh: How Brokers Link Plants, Data Centres and Clouds

A Solace event mesh is a set of Solace Event Brokers, running wherever your applications run, that behave as one routing fabric: an event published at one plant reaches every broker whose clients subscribed to its topic, and nowhere else. Solace’s documentation defines it as “a network of event brokers that allows events from one application to be dynamically routed and received by any other application, no matter where these applications are deployed”, on premises, in a private cloud or in a public cloud. The mechanism underneath is Dynamic Message Routing (DMR).

This page explains how a mesh is built from clusters, links and gateway nodes, why it matters when a business runs many plants and more than one cloud, how it compares with a single broker or a streaming platform, and what to check before you commit. For the company and the rest of the portfolio, start at the Solace hub. For the vendor-neutral concept, see what is an event mesh.

What a Solace event mesh is, and what it is not

It is a capability of the broker, not a separate product. Every Solace Event Broker form factor (software, appliance and Solace Cloud) can join a mesh. Solace lists “Event Mesh” as its own item in the product navigation and “Dynamic Routing” as a platform feature, but there is nothing extra to install: the brokers link to each other and exchange subscription information.

It routes on demand rather than copying everything. A broker learns which topics the clients of other brokers want, and forwards an event across a link only when someone on the far side has a matching subscription. This is the property that separates a mesh from a set of point-to-point bridges, and it is why the topic hierarchy matters so much: the topic is the routing key for the whole estate.

It is not a service mesh, and it is not a data lake. A service mesh manages synchronous calls between microservices. An event mesh moves asynchronous events. Neither keeps long histories by default: Solace offers message replay from a per-VPN replay log, but long retention for analytics is the job Kafka and lakehouses were built for.

The term predates the product rename. “Event mesh” is a term Solace has promoted for years, and SAP uses it in the names of its eventing products, including SAP Integration Suite, advanced event mesh, which is built on Solace technology. Gartner’s 2024 Market Guide for Event Brokers lists Solace among 20 representative vendors; market guides do not rank vendors.

How the Solace event mesh is built: clusters, links and gateways

The DMR documentation describes three building blocks. A cluster is a group of broker nodes in which every node connects to every other node over internal links. Clusters connect to each other over external links, through a gateway node in each cluster. Internal links give horizontal scale inside a site; external links give reach across sites and clouds.

Building block	What it is	Why it matters
Event Broker node	One broker (software, appliance or cloud service), usually an HA group	The unit you size, license and patch
Message VPN	A virtual broker inside a broker, with its own topics, clients and queues	DMR links connect matching VPNs; see Message VPNs and security
DMR cluster	Nodes joined in a full mesh by internal links	Scales one site horizontally
External link and gateway node	The connection between two clusters, through one gateway each	Where WAN, firewall and cloud egress decisions land
Mesh Manager	Solace Cloud tool that creates the links between Enterprise services	Removes hand configuration in the cloud; not for self-managed brokers
Message VPN bridge	An older, explicitly configured link between two VPNs with a fixed topic list	Still useful at a firewall where you want a fixed allow-list
Multi-Node Routing (MNR)	The legacy routing technology	Cannot be used together with DMR

Subscriptions travel one way, events travel back. When a client subscribes, its broker advertises the subscription to its neighbours, and the gateway advertises the whole cluster’s subscriptions to the connected clusters. Events then follow those advertisements in reverse, one copy per link. The mechanics, including why loops cannot form, are on dynamic message routing.

Quality of service is preserved end to end. Solace states that DMR carries both Direct and Guaranteed messages and keeps the delivery mode the publisher chose. A Guaranteed event for a node that is down stays queued on its neighbour until delivery; a Direct event published during an outage is lost. That distinction decides which plant events must be published as Guaranteed, which is covered on guaranteed messaging.

Why a Solace event mesh matters across plants, clouds and regions

Consider an illustrative manufacturer with six plants, an SAP system in a corporate data centre, a data platform in one public cloud and a quality application in another. Each plant produces order confirmations, downtime events, quality results and line states. Without a mesh, every new consumer means another point-to-point integration: a new file drop, a new API poll, a new bridge to configure and monitor. After five years the integration map is the hardest thing in the business to change.

With a mesh, each plant publishes once to its local broker under an agreed topic structure. The ERP connector subscribes to confirmations from all sites with one wildcard. The cloud data platform subscribes to the streams it needs. The plants keep working if the WAN drops, because their local broker is still there, and Guaranteed events queue until the link returns.

Three consequences follow for the business:

1. Adding a consumer stops being a project. A new application subscribes to existing topics; nobody changes the publisher.
2. Bandwidth follows demand. A plant event that nobody outside the plant subscribes to never leaves the plant, which matters on thin WAN links and on cloud egress bills. See hybrid and multi-cloud.
3. The plant stays autonomous. Local consumers keep running through a WAN outage, which is the property plant managers ask about first.

Solace’s published references describe this pattern at scale. Solace states that Danone runs an event mesh across more than 100 production sites and 300 distribution centres, integrating MES, WMS, SAP and IoT. We have not verified those figures independently.

Event mesh, single broker or streaming platform?

Not every estate needs a mesh. The same dimensions for each option:

Dimension	Single central broker	Solace event mesh	Kafka with cross-cluster replication
Where clients connect	One site; remote sites connect over the WAN	Their local broker, at every site	Their regional cluster
What crosses the WAN	Every message, both ways	Only events someone subscribed to	Whole replicated topics
WAN outage at a plant	Plant clients lose the broker	Plant keeps working; Guaranteed events queue	Plant keeps working if it has its own cluster
History and replay	Broker-dependent	Replay log per VPN, sized for recovery	Long retention is the core design
Protocols at the edge	Broker-dependent	MQTT, AMQP, JMS, REST, WebSocket, SMF on every node	Kafka protocol; MQTT through connectors or proxies
Operational effort	Lowest	One broker estate to run and upgrade	One or more clusters plus replication tooling
Best fit	One site, or a few sites with reliable links	Many sites and clouds with live, selective distribution	Analytics, retention and stream processing

Our view: a single broker is the right answer more often than vendors suggest. A mesh earns its cost when there are several sites or clouds, consumers in more than one place, and WAN links you cannot trust. Kafka and a mesh are often complementary rather than rivals: the mesh distributes live events, and Kafka keeps the log for analytics. The Solace alternatives page and the neutral event-driven architecture guide go further.

Where the mesh fits in a manufacturing architecture

In an ISA-95 view, the defensible place for a Solace event mesh is the boundary between site operations and the enterprise. Solace’s own April 2026 UNS article describes a mesh that “connects brokers across sites, regions, and clouds into a unified fabric” and argues for evolving a plant unified namespace, not replacing it. Its June 2026 article on broker placement places an edge broker at each plant as “the controlled meeting point” between OT and IT, at what Purdue practitioners call level 3.5.

That leaves two common designs. In the first, a plant MQTT broker or Ignition serves the line, and a Solace broker at the site boundary bridges selected topics into the mesh. In the second, the Solace broker is also the plant’s MQTT broker. The second is simpler, but it inherits the MQTT limits listed below. The manufacturing section and multi-site edge to cloud cover both designs, and our unified namespace guide explains the plant layer.

Limits and open questions

• The free Standard Edition is not a production mesh. Solace’s edition table lists DMR on Standard as performance-capped, with one Message VPN, no DR replication and “Production Deployable: No”. See Standard vs Enterprise.
• Mesh Manager is for Solace Cloud only. Its documentation covers Enterprise event broker services; a service can belong to only one mesh. Self-managed software brokers and appliances are linked by configuration, through the CLI, SEMP or Terraform.
• No public pricing. Solace’s pricing page places Mesh Manager’s Link Builder in the Accelerate package but publishes no prices, as of October 2026. See editions and pricing.
• MQTT behaviour carries across the mesh. Solace documents that MQTT QoS 2 is downgraded to QoS 1, QoS 1 shared subscriptions are downgraded to QoS 0, and retained messages rely on retain caches in Controlled Availability.
• Sparkplug B is self-tested, not listed. A 2023 community post reported a Sparkplug TCK pass on broker 10.5; Solace is not on the Eclipse compatible-products list.
• Kafka bridging is documented for software brokers only. If the mesh must feed Kafka from an appliance or a cloud service, confirm the path. See Kafka integration.
• The full-mesh requirement grows quickly. Ten clusters joined directly need 45 external links. Ask how the design scales before the twentieth plant.

How to evaluate a Solace event mesh

• Which events must cross sites, and which can stay local? Write the list before drawing the mesh.
• Is there an agreed topic hierarchy that every site will follow? Without it, wildcards and routing will not work.
• Which events must be Guaranteed, and how long must they queue during a WAN outage? Size the spool from that.
• Which clusters need direct links to each other, and who owns the firewall rules for each?
• Will brokers be self-managed, Solace Cloud services, or both, and who links them?
• How will we monitor link health and subscription counts across sites?
• Does the plant layer need QoS 2, retained messages or Sparkplug state handling?
• What does the mesh cost at our scale, including support and cloud egress, as a written quote?

If the network side of these questions has no owner, an IT/OT integration review is the right first step.

Deeper

• Dynamic Message Routing: how subscriptions propagate, how events are forwarded, why loops cannot form, and where DMR gets hard
• Hybrid and Multi-Cloud: on-premises plus AWS, Azure and Google Cloud, the deployment ownership models, latency, egress and data residency
• Message VPNs and Security: multi-tenancy, authentication, ACLs, TLS, and how the mesh respects IT and OT zones

Back to the Solace hub, or across to the messaging model, where topics and queues are explained, and Solace Cloud, where Mesh Manager lives.