Solace Architecture: Data Plane, Control Plane and Where Each Runs

Solace architecture is easiest to understand in two planes. The data plane is what moves events: event brokers, divided into Message VPNs, made highly available in groups, and linked into an event mesh by dynamic message routing. The control plane is what creates, configures and watches those brokers: the Solace Home Cloud and its console, Mission Control and its agent, Event Portal, Insights, and the broker’s own management interfaces. The two planes can run in different places, and knowing which traffic is which is what an architecture review and a network security review both need.

“Data plane” and “control plane” are our lens; Solace’s own documentation groups the products as a core of brokers, application services and platform services (What Is Solace Platform?). This page belongs to the Solace Platform overview in the Solace cluster.

The data plane: brokers, VPNs and the event mesh

The broker is the unit. Every Solace deployment is built from Solace Event Brokers: a managed service in Solace Cloud, software on VMs, Docker or Kubernetes, or a hardware appliance. Clients connect over SMF (Solace’s own protocol), MQTT, AMQP, JMS, REST or WebSocket, and the broker routes by hierarchical topic.

Message VPNs divide a broker. A Message VPN is a virtual broker with its own topics, queues, clients and access control. It is the multi-tenancy boundary: production and test, or IT and OT, can share hardware without sharing data. The Standard Edition allows one, the Enterprise Edition five (edition comparison). Message VPNs and security covers the access model.

High availability is a three-node group. A software HA group has a primary, a backup and a monitoring node that breaks ties to prevent split-brain. The pair runs active and standby with configuration sync, and clients fail over through a host list (redundancy docs). HA and disaster recovery goes further.

Replication protects a site. Disaster recovery replicates guaranteed messages from an active site to a standby site, synchronously or asynchronously, configurable per topic. On software brokers it is an Enterprise Edition feature.

Dynamic message routing makes the mesh. With DMR, brokers propagate subscriptions to each other and forward events only where a subscriber exists. Internal links form a full mesh inside a cluster to scale horizontally; external links connect clusters across sites and clouds. Solace defines the result, 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”. The legacy Multi-Node Routing cannot be combined with DMR. Dynamic message routing explains subscription propagation.

The control plane: how brokers are created, configured and observed

For Solace Cloud services, the Home Cloud is the control point. The Solace Cloud Console and Mission Control create, scale and upgrade broker services. When brokers run in a customer’s own Kubernetes, a Mission Control Agent runs beside them; Solace’s docs say it “creates a secure connection back to the Solace Home Cloud and relays user commands from the console to the software event brokers” (ownership models). Mission Control covers fleet management.

For self-managed brokers, management is local. Broker Manager (a web UI), the Event Broker CLI, the SEMP management API and Terraform providers configure each broker directly.

Design and observation sit beside both. Event Portal holds the design-time catalogue and, through the Event Management Agent, discovers what is actually configured on brokers, including Kafka. Insights and broker-native OpenTelemetry tracing show runtime behaviour, with export to APM tools.

Solace architecture by component: where each part runs

Component	Plane	Runs where	Managed through
Event broker service	Data	Solace public or dedicated clusters, or customer Kubernetes	Solace Cloud Console, Mission Control
Software broker	Data	Your VMs, Docker, Kubernetes or OpenShift	Broker Manager, CLI, SEMP, Terraform
Appliance (3560, 3530)	Data	Your data centre or edge	CLI, SEMP, Broker Manager
DMR links and replication	Data	Between brokers	Broker configuration, Mesh Manager
Mission Control Agent	Control	Beside customer-controlled brokers	Solace Home Cloud
Event Portal and Event Management Agent	Control (design time)	Solace Cloud; the agent runs near the brokers	Event Portal
Insights and distributed tracing	Control (observability)	Solace Cloud, with export to APM tools	Insights, OpenTelemetry Collector

Solace now calls the three Solace Cloud models public, dedicated and customer-controlled clusters; older pages say regions. Solace Cloud covers the responsibility split.

An illustrative plant-to-cloud layout

This scenario is illustrative. A manufacturer places a software broker HA group at each plant at ISA-95 Level 3, beside SCADA and MES, typically in or near the industrial DMZ. A DMR external link from each plant broker reaches an event broker service in a dedicated cluster in the cloud, where ERP integration and analytics subscribe. Plant applications see only the plant broker; the cloud sees only the topics it subscribes to.

What crosses the DMZ. One outbound broker-to-broker link per plant carries events, and, if used, management or telemetry traffic for Insights or the Event Management Agent. That is a short, reviewable list, which is the argument for a broker per plant rather than plant clients connecting straight to the cloud. How it fits your zones and conduits is a question for an OT network assessment, and our guide to OT network segmentation in brownfield plants covers the zoning. Multi-site edge to cloud takes the pattern further.

Decisions the Solace architecture forces

1. Broker per site, or shared? A broker per plant keeps local traffic local and survives WAN loss; a shared regional broker costs less to run.
2. How many Message VPNs, and for what? Split by environment, by tenant, or by IT and OT, within the edition’s limit.
3. HA everywhere? HA groups need three nodes. Decide which sites justify them.
4. Which form factor where? Cloud services where you want no broker team, software where data must stay on site, appliances where latency or air gaps demand them.
5. Which management path? Solace-managed through the Home Cloud, or local through SEMP and Terraform. Mixing both is common; document which owns each broker.
6. Where does the topic hierarchy come from? DMR routes by subscription, so a consistent topic design decides how efficiently events cross sites.

Where it gets hard

• Control-plane dependency is not fully documented. The page we reviewed does not say what happens to customer-controlled brokers if the link to the Home Cloud drops. Ask Solace before a plant depends on it.
• DMR and Multi-Node Routing do not mix. Older estates on MNR need a migration plan.
• Edition limits shape the architecture. One Message VPN and no replication on Standard means a design proven on Standard may not survive a move to production unchanged.
• Kafka bridging is documented for software brokers only, which constrains where a Kafka connection can terminate.
• Two management paths drift. A broker changed through the CLI and also through the console needs one owner.

---

Related: Solace Platform · Editions and Pricing · Releases and LTS · Solace event mesh · Solace hub