What Is an Event Mesh? Connected Brokers Across Plants, Data Centres and Clouds

What is an event mesh? It is a network of interconnected event brokers that routes events between applications wherever they run: on a plant floor, in a data centre or in a cloud region. Each application connects to the broker nearest to it. When a consumer subscribes, the mesh learns where that interest lives, and events published anywhere on the mesh find their way to it, with buffering when a link fails and filtering so that only wanted events cross the WAN.

The term was popularised by Solace, which defines an event mesh 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” (Solace docs). SAP adopted the phrase as a product name, and analysts use it as a category. This page describes the concept independently of any one vendor, as part of our event-driven architecture guide.

Why an event mesh exists: the multi-site problem

One broker serves one site well. Inside a plant, a clustered MQTT or messaging broker handles the SCADA, MES and dashboard traffic with low latency. The difficulty begins when events must leave the site. A manufacturer with ten plants, a corporate data centre and a cloud tenant faces questions a single broker does not answer:

• Where does a consumer connect? If the quality system runs in the cloud, does it open connections to ten plant brokers, or do ten plants push to the cloud?
• What happens when the WAN drops? Events produced during the outage must wait somewhere and arrive later, in order.
• What crosses the link? Sending every tag change from every plant to the cloud is expensive and usually pointless. Only events someone has subscribed to should travel.
• Who is allowed to see what? A supplier portal may see shipment events from one plant, never process data from another.

The traditional answer is a hand-built bridge per flow: a script or connector that copies topic A on broker 1 to topic B on broker 2. It works for three flows. At fifty, nobody knows which bridges exist, which are healthy, or what would break if one stopped. An event mesh replaces those bridges with a routing layer that is configured once and maintained as a system.

Event mesh vs single broker, hub and spoke, and streaming cluster

The four designs below all move events between places. They differ in where routing decisions are made and what happens when a link fails.

Design	How events move between sites	Strength	Weakness
Single central broker	Every plant connects to one broker in the data centre or cloud	Simple to run and secure	Every plant depends on the WAN in real time; local consumers pay a round trip
Hub and spoke with bridges	Each plant has a broker; bridges copy chosen topics to a central broker	Plants keep working offline; familiar	Bridges are configured per flow; consumers at one plant rarely see another plant’s events
Streaming cluster with replication	Each region runs a log cluster; topics are mirrored between clusters	Durable history and replay in every region	Replicates whole topics, not individual subscriptions; heavier footprint at small sites
Event mesh	Brokers at every location are linked; subscriptions propagate and events route on demand	Any consumer anywhere; only subscribed events cross links; buffering per link	More to design up front; the strongest implementations are commercial

How vendors build an event mesh: four mechanisms

“Event mesh” is a description of an outcome, and products reach it in different ways. Asking which mechanism a product uses tells you more than whether its marketing uses the word.

Mechanism	How it works	Examples (as documented by each project or vendor)
Dynamic subscription routing	Brokers exchange subscription interest and forward each event only to brokers with a matching subscriber	Solace Dynamic Message Routing (Solace); SAP Integration Suite, advanced event mesh, which is built on Solace
Clusters, gateways and leaf nodes	Servers form clusters, clusters join through gateways, and remote servers attach as leaf nodes over an outbound connection	NATS: “a leaf node is a NATS server that opens an outbound connection to a remote NATS system and bridges subject interest across it” (NATS docs)
Topic replication	Whole topics are copied between clusters, keeping order and history	Kafka MirrorMaker 2 (Kafka docs); Confluent Cluster Linking, which mirrors topics “with byte-for-byte replication” (Confluent); Pulsar geo-replication (Pulsar)
Bridging and federation	Configured links copy selected topics or queues between brokers	MQTT broker bridges, RabbitMQ federation and shovel, HiveMQ and EMQX bridging features

The first two route by interest; the last two copy by configuration. Interest-based routing scales better as consumers come and go. Replication is better when every region needs the full history for analytics. Bridging is simplest for a handful of known flows. A manufacturer can reasonably use more than one: bridges from plant MQTT brokers into a backbone, and replication from the backbone into a cloud analytics cluster.

What an event mesh must handle in a manufacturing estate

WAN outages are normal. Plants lose links to the data centre for minutes or hours. The mesh must queue events at the edge of each link and deliver them in order when the link returns, and the queue must be sized for the longest outage you plan to survive. Ask what happens when it fills.

Filtering belongs at the source. A plant can produce tens of thousands of tag changes a second. Only a fraction is needed off site. A mesh that forwards by subscription keeps the rest local, which protects both the WAN and the cloud bill.

Security zones still apply. A mesh link that crosses from the plant network to the enterprise network is a conduit in IEC 62443 terms. It should be initiated from the more trusted side or pass through a DMZ broker, carry TLS, and be limited by topic-level access control. Our guide to OT network segmentation in brownfield plants explains zones and conduits, and the Solace message VPN page shows how one vendor separates tenants on a shared mesh.

Data residency and ownership. Some events must stay in a country or a site. A mesh needs a way to say “this topic never leaves plant B”, and that rule needs an owner.

Loops and duplicates. Any multi-path topology can deliver an event twice or forward it in a circle if misconfigured. Mature implementations prevent loops by design; consumers should still de-duplicate by event id.

When you need an event mesh, and when you do not

You probably need one when several of these are true: events must reach consumers in three or more locations; plants must keep producing through WAN outages without losing data; enterprise systems need guaranteed delivery from many plants; several protocols (MQTT at the edge, JMS or AMQP in IT, Kafka in the data platform) must meet; and a central team will own the design.

You probably do not when there is one site, or a few sites that only send data to one cloud analytics platform. A clustered plant broker plus a bridge, or a cloud ingestion service, is simpler and cheaper. Our UNS broker guide walks through that decision for the plant layer.

Limits and open questions

• The term is not standardised. No standards body defines “event mesh”. Vendors apply it to quite different mechanisms, so compare mechanisms, not labels.
• Interoperability between vendors is limited. Meshes are usually built from one vendor’s brokers. Joining two vendors’ brokers generally falls back to bridging over a common protocol such as MQTT or AMQP, with the per-flow configuration that implies.
• Operations need a central team. A mesh is shared infrastructure. Without an owner for topics, access and capacity, it decays into the same sprawl it was meant to replace.
• Licensing scales with locations. Commercial meshes are typically priced per broker, capacity or connection, and public prices are rare. Model the cost at your target number of sites, not the pilot.
• Analytical history is a separate question. Routing meshes keep events until they are delivered. Long retention and replay for analytics usually still needs a streaming platform alongside.

How to evaluate an event mesh

• Which mechanism does it use: subscription routing, gateways, replication or bridging?
• How much does each plant buffer during a WAN outage, and what happens when the buffer is full?
• Can routing be restricted so that named topics never leave a site?
• Which protocols can publish into it and consume from it, and are any features downgraded on some protocols?
• How are topics, access rights and links configured across sites: one console, code, or per broker?
• How does it connect to the Kafka or cloud streaming platform the data team already runs?
• What is the smallest footprint that can run at a plant, and who supports it there?
• How is it licensed at ten sites, and at fifty?

If the answers depend on how your plants, DMZs and WAN are laid out, an IT/OT integration review is where we would start, before any product shortlist.

Deeper

There are no child pages under this guide yet. These pages go further:

• Solace Event Mesh: one vendor’s implementation in depth, independently reviewed
• Solace Dynamic Message Routing: how subscription propagation works in practice
• Solace hybrid and multi-cloud: plants, data centres and three clouds on one mesh
• Event Broker Comparison: the products behind each mechanism, on the same dimensions
• Kafka vs MQTT: where the streaming log fits beside the mesh

Back to the event-driven architecture hub.