Solace Messaging Explained: Topics, Queues and Delivery Modes

Solace messaging is the set of rules the Solace Event Broker (formerly PubSub+ Event Broker) uses to move a message from the application that publishes it to the applications that need it. It rests on three ideas. Every message is published to a hierarchical topic. It travels in one of two delivery modes, direct or guaranteed. And it reaches consumers through one of three exchange patterns: publish-subscribe, point-to-point or request-reply. What sets Solace apart from many brokers is that topics and queues are not alternatives: queues subscribe to topics, so one published event can fan out to live subscribers and to several durable queues at once.

This page explains those ideas for an architect or integration lead who knows plants but not this broker, and where each choice matters. It sits in the Solace cluster; the broker itself is covered on the Event Broker page.

How Solace messaging works: the moving parts

Four terms carry the whole model.

• Topic. A string such as mfg/machine/stateChanged/v1/mtl/packaging/line3/filler that describes what the message is about. Publishers send to a topic; they never address a consumer. Topics are hierarchical and filtered with wildcards, covered in depth on topics and wildcards.
• Subscription. A topic pattern a client or a queue registers with the broker. The broker matches each message’s topic against all subscriptions and delivers a copy to every match.
• Endpoint. Somewhere the broker stores guaranteed messages for a consumer. Solace has two kinds, queues and topic endpoints, and its endpoint documentation states that queues “are significantly more flexible than topic endpoints and are the recommended approach for most applications”. Topic endpoints exist mainly for JMS durable subscriptions.
• Delivery mode. Direct or guaranteed. This decides whether the broker stores the message and waits for acknowledgements, or forwards it and forgets it.

The decoupling is the point. A filler PLC’s gateway publishes a state change once. The MES, the historian, a downtime dashboard and next year’s analytics project each subscribe without the publisher changing a line of configuration. That is the property that makes event-driven integration cheaper to extend than point-to-point interfaces, and it is why the event-driven architecture guide starts from it.

The three exchange patterns in Solace messaging

Solace’s message exchange patterns page defines three, and they map directly onto the classic publish-subscribe channel and point-to-point channel from Enterprise Integration Patterns.

Pattern	Who receives a message	Typical plant use	Usual delivery mode
Publish-subscribe	Every matching subscriber gets a copy	Machine states, counts and alarms feeding MES, historian and dashboards	Direct for live views, guaranteed where a gap matters
Point-to-point	One consumer per message, shared across a consumer group	Production orders, quality results, work for a pool of integration workers	Guaranteed, from a queue
Request-reply	The responder, then the requester gets the answer	Recipe or master-data lookups, label print requests, a command with a confirmation	Either, chosen per call

Point-to-point scales by adding consumers. A non-exclusive queue lets several instances of one service share the load; the docs call these consumer groups and note that “each message is still only delivered to a single endpoint”. When the order of related messages matters, the answer is a partitioned queue, which keeps order per key while still scaling out.

Request-reply is two one-way flows. Solace describes it as “separate point-to-point channels: one for requests, and another for replies”. The requester names a reply-to destination and the APIs correlate the answer. It is useful, but it couples the requester to a timely responder, so keep it for questions that genuinely need an answer, not for broadcasting state.

Direct vs guaranteed: the delivery mode decision

The second choice is how much the broker promises. Solace’s delivery modes page puts the difference plainly: direct messages “are not acknowledged upon delivery” and “can be discarded when congestion or system failures are encountered”, while guaranteed messages “can’t be lost once they are acknowledged by the event broker”.

Property	Direct	Guaranteed
Acknowledgements	None	Broker acknowledges the publisher; consumer acknowledges the broker
Storage	Not stored for a disconnected client	Spooled to persistent storage on a durable endpoint until consumed
Loss	Possible under congestion or failure	Not lost once accepted (publishing can be refused if spool limits are hit)
Cost	Lowest latency and highest rate	Disk writes, acknowledgements and spool capacity to plan
Fits	Live values a newer value will replace	Orders, confirmations, quality records, anything audited

The rule of thumb for a plant: if a missed message would be noticed by an auditor, a customer or an accountant, it is guaranteed. A temperature published every second for a trend screen can be direct, because the next value arrives in a second. A batch-complete event that triggers goods receipt in ERP must be guaranteed, because nothing will resend it. The mechanics of acknowledgements, spooling and redelivery are on queues and guaranteed messaging.

The modes meet at the broker. If a direct message matches a queue’s subscription, Solace promotes it: it is spooled and from then on must be acknowledged off the queue. If a persistent message matches a direct subscriber, it is demoted and delivered without guarantees, which Solace notes can produce duplicates. Promotion is useful in practice: a gateway can publish direct, and the one consumer that needs durability simply reads from a queue.

Topics feed queues: why the model is different

In many queue-first brokers, a producer publishes to a named queue, and adding a second consumer of the same data means changing the producer or adding a copy step. In Solace, the producer publishes to a topic, and a queue is just another subscriber that happens to store what it attracts. The endpoints page describes adding “one or more topic subscriptions to a durable endpoint so that Guaranteed messages published to matching topics are delivered to that endpoint”.

An illustrative scenario. A packaging line publishes .../line3/filler state changes. The MES integration owns a queue subscribed to every line’s state topics. The quality team adds its own queue subscribed only to fillers across all sites. The downtime dashboard subscribes directly, with no queue at all, because it only needs live values. Nobody touched the publisher, and each consumer’s backlog, outage or redeployment affects only its own queue. That isolation is the practical benefit: a slow MES upgrade does not stall the dashboard.

The cost is design discipline. Because consumers select data by topic pattern, the topic hierarchy becomes an interface contract that is hard to change later. Getting it right for a plant is the subject of the topics and wildcards page. Our MQTT guide for manufacturing covers the same idea from the plant broker side.

What Solace messaging means for a plant architecture

Most plants meet these concepts at the boundary between the line and the business. Plant-floor collection usually runs over MQTT or OPC UA into a SCADA or a plant broker, and the Solace manufacturing page describes where an enterprise broker sits above that. In our view the messaging model earns its keep in three places:

1. Events that must arrive. Production confirmations, genealogy and quality results into MES and ERP, where guaranteed delivery replaces nightly reconciliation jobs.
2. Many consumers of the same event. One line event feeding five systems without five interfaces.
3. Recovery. Queues absorb an outage of a consumer, and message replay lets a repaired or new consumer re-read history.

If your team is mapping which flows need which guarantee, that is the core of an IT/OT integration design, and it is worth doing before choosing any broker.

Limits and open questions

• MQTT clients get a subset. Solace’s MQTT documentation states that 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. Plant designs that assume full MQTT semantics need checking; see Solace and MQTT.
• Sparkplug B is unproven at the listing level. A 2023 community post reported a Sparkplug compliance test run against broker 10.5, but Solace is not on the Eclipse compatible-software list as of October 2026.
• The free Standard Edition is not for production. The edition table marks Standard “Production Deployable: No”, with a 10,000 msg/s ingress limit and an 800 GB maximum spool. Guaranteed messaging is there to evaluate, not to run a plant on.
• Some features do not combine. Message replay is not supported on partitioned queues, and the docs state replication with replay is not supported.
• Dead message handling changed between releases. Behaviour differs from 10.25.10 onwards, and 10.26.0 (the current LTS as of October 2026) added endpoint-level overrides. Check the release you run.
• Topic endpoints are a legacy shape. Solace recommends queues; topic endpoints mostly serve JMS durable subscribers.

How to evaluate Solace messaging for your flows

• Have we listed each data flow and decided direct or guaranteed for each, with a reason?
• Do we have a topic hierarchy agreed across sites, versioned, and owned by someone?
• Which consumers need their own queue, and who owns each queue’s quota and alerts?
• Where does order matter, and is it per machine, per order or global?
• Which clients will speak MQTT, and do any rely on QoS 2, retained messages or Sparkplug?
• How will we monitor spool usage, queue depth and dead messages?
• Do we need replay, and for how many days of history?
• Which broker release will we standardise on, and does it include the features above?

Deeper

• Topics and wildcards: hierarchical topics, * and >, and an ISA-95-shaped topic tree for a plant with good and bad examples
• Queues and guaranteed messaging: spooling, acknowledgements, exclusive vs non-exclusive queues, redelivery and dead message queues
• Partitioned and last value queues: ordering with scale-out, and holding only the current state
• Message replay: the replay log, start points, recovery use cases and the limits

Back to the Solace hub, or across to protocols and APIs, which covers how MQTT, JMS, AMQP and REST clients reach this model, and the event mesh, which carries it between sites.