Solace PubSub+

Every messaging technology in this book has an origin story that reveals something about its priorities. Kafka was born from LinkedIn's data firehose. RabbitMQ emerged from the telecom world's need for reliable message queuing. Solace started life as a hardware appliance company selling purpose-built messaging boxes to financial institutions. That origin — silicon, not software — shapes everything about what Solace PubSub+ is today, for better and for worse.

Solace occupies a peculiar position in the messaging landscape. It is simultaneously one of the most feature-rich platforms available and one of the least discussed in developer communities. You will not find it dominating Hacker News threads or Stack Overflow questions. But walk into a large bank, a global logistics company, or an automotive manufacturer's integration team, and there is a reasonable chance Solace is quietly moving millions of messages per second beneath the surface. It is the enterprise dark horse — technically impressive, commercially significant, and almost entirely invisible to the broader developer consciousness.

This chapter examines Solace PubSub+ honestly: what it does well, what it does not, and whether its enterprise-oriented design is a strength or a limitation depending on your context.

Overview

What It Is

Solace PubSub+ is a multi-protocol event broker that supports publish-subscribe messaging, message queuing, request-reply, and event streaming. It is available as a software broker, a managed cloud service (PubSub+ Cloud), and — uniquely among modern brokers — a hardware appliance. The platform's distinguishing feature is its "event mesh" vision: the ability to interconnect multiple brokers across data centres, clouds, and edge locations into a unified messaging fabric.

Brief History

Solace Systems was founded in 2001 in Ottawa, Canada, by Craig Betts. The original premise was that general-purpose servers running software-based message brokers could not deliver the latency and throughput that financial services firms needed. Solace's answer was purpose-built hardware: custom ASICs and FPGAs designed specifically for message routing. If you wanted single-digit microsecond message latency in 2005, your options were essentially Solace appliances, 29West (later acquired by Informatica), or writing your own kernel-bypass solution and hoping your team included someone who understood FPGA programming.

The hardware appliance business was profitable but inherently limited in addressable market. Not everyone needs — or can afford — custom messaging hardware. Around 2014-2015, Solace began a strategic pivot: they ported the broker's functionality to a software-only deployment. The software broker maintained the same API, protocol support, and management interfaces as the appliance but ran on commodity hardware and, crucially, in virtual machines and containers.

In 2019, Solace launched PubSub+ Cloud, their fully managed service offering. This completed the transformation from niche hardware vendor to multi-modal messaging platform. The company rebranded from "Solace Systems" to simply "Solace" and pushed heavily into the "event mesh" narrative — positioning itself as the connective tissue for enterprise event-driven architectures spanning multiple clouds and on-premises data centres.

Solace remains a private company, which means limited public financial data. They have raised venture funding and claim thousands of enterprise customers. The customer base skews heavily toward financial services, logistics, healthcare, and large-scale manufacturing — industries where multi-protocol support, guaranteed delivery, and enterprise-grade management are table stakes, not nice-to-haves.

Who Runs It

Solace the company develops and maintains PubSub+ as a commercial product. There is no open-source core in the Apache Kafka sense. The software broker has a free "Standard" edition with capacity limits, and there are "Enterprise" and "Mission Critical" tiers with progressively more features and capacity. PubSub+ Cloud has a free tier as well, which is genuinely useful for development and small-scale testing.

This is important to understand: Solace is a commercial product first. The community edition exists to lower the adoption barrier, but the business model is enterprise licensing and cloud subscriptions. If you are philosophically committed to open-source infrastructure, Solace is probably not for you. If you are pragmatically committed to solving enterprise messaging problems and have a procurement department, keep reading.

Architecture

The Broker

At its core, PubSub+ is a message broker — a process that accepts connections from clients, receives messages, and routes them to interested consumers. So far, standard fare. What distinguishes Solace architecturally is the breadth of messaging patterns it supports natively and the efficiency of its internal routing engine.

The broker is written in C/C++, not Java. This is relevant because it means PubSub+ does not suffer from JVM garbage collection pauses. For workloads that require consistent low-latency message delivery — financial market data, real-time control systems — GC pauses are not a theoretical concern but a concrete operational headache. Solace avoids this category of problem entirely.

The broker process manages:

  • Client connections across multiple protocols simultaneously (more on this below)
  • Message routing using a topic-based hierarchy with wildcard subscription support
  • Persistent message storage for guaranteed delivery
  • Message replay for re-consuming historical messages
  • Queue management for competing consumer patterns

A single broker instance can handle tens of thousands of concurrent client connections and millions of messages per second, depending on message size and delivery guarantees. The hardware appliance version pushes these numbers significantly higher — Solace claims sub-microsecond latency on their appliance, which is believable given the dedicated FPGA routing path.

Message VPNs

One of Solace's more useful architectural concepts is the Message VPN (Virtual Private Network). A Message VPN is a virtual partition of the broker that provides complete isolation of messaging resources: topics, queues, client connections, and access controls.

Think of it as multi-tenancy at the broker level. A single PubSub+ broker can host multiple Message VPNs, each with its own:

  • Client username/password database or LDAP/RADIUS integration
  • Topic space (the same topic name in two different VPNs refers to different logical destinations)
  • Queues and subscriptions
  • Rate limits and connection quotas
  • ACLs and access profiles

This is genuinely valuable in enterprise environments where a single messaging infrastructure needs to serve multiple teams, applications, or business units with isolation guarantees. You can run development, staging, and production traffic on the same broker cluster by separating them into different VPNs — though whether you should is a separate discussion about blast radius and risk appetite.

Guaranteed and Direct Messaging

Solace distinguishes between two fundamental messaging modes, and understanding this distinction is essential:

Direct Messaging is fire-and-forget. The producer sends a message, the broker routes it to all matching subscribers, and if a subscriber is not connected or cannot keep up, the message is lost. Direct messaging is fast — it avoids the overhead of persistence, acknowledgement, and retry — and is appropriate for data that is time-sensitive but not individually critical. Market data ticks, sensor readings, and real-time metrics are classic direct messaging use cases. If you miss one price update, the next one arrives in milliseconds and supersedes it.

Guaranteed Messaging provides once-and-only-once delivery semantics. Messages are persisted to queues, acknowledged by consumers, and redelivered on failure. The broker writes messages to disk (or to the hardware appliance's memory), maintains delivery state per consumer, and ensures that every message reaches its intended destination even if consumers disconnect or crash.

The two modes can coexist on the same broker, which is useful because most real-world systems have a mix of "best effort is fine" and "every message matters" requirements. A trading system might use direct messaging for streaming quotes and guaranteed messaging for order execution confirmations.

Topic Hierarchy and Subscriptions

Solace uses a hierarchical topic structure with levels separated by slashes:

orders/region/EMEA/currency/EUR
orders/region/APAC/currency/JPY
sensors/building-7/floor-3/temperature

Subscribers can use wildcards:

  • * matches a single level: orders/region/*/currency/EUR matches all EUR orders regardless of region
  • > matches one or more levels at the end: sensors/building-7/> matches all sensors in building 7

This is more expressive than Kafka's flat topic names and simpler than RabbitMQ's exchange/binding/routing-key model. The hierarchical topic system allows fine-grained subscription without requiring message filtering at the consumer level. Consumers receive only the messages that match their subscription, which reduces bandwidth and processing overhead.

The broker maintains a subscription routing table that maps topic patterns to connected consumers. The routing engine evaluates incoming messages against this table and delivers copies to all matching subscribers. On the hardware appliance, this routing is performed by custom silicon; on the software broker, it is an optimised C++ implementation.

High Availability and Redundancy

PubSub+ supports an active-standby redundancy model for high availability. Two brokers (or appliances) operate as a redundancy pair:

  • The primary broker handles all client traffic and message routing
  • The backup broker maintains a synchronised copy of all persistent state
  • If the primary fails, the backup takes over with minimal message loss

The failover is automatic and typically completes in seconds. Clients using the Solace SDK (with configured host lists) reconnect automatically. This is simpler than Kafka's partition-leader model or Pulsar's bookie architecture, but it comes with a trade-off: the active-standby model does not provide horizontal scaling for message routing. A single broker (or redundancy pair) handles all traffic. You scale by adding more Message VPNs, using event mesh to distribute load across sites, or — honestly — buying a bigger box.

For the hardware appliance, "buying a bigger box" is literal. Solace sells appliance models with progressively more capacity. For the software broker, you scale vertically (more CPU, more memory, faster disks) or distribute horizontally using DMR.

Protocol Support

This is where Solace genuinely shines, and where its enterprise heritage becomes an unambiguous advantage.

PubSub+ natively supports:

  • SMF (Solace Message Format): Solace's proprietary binary protocol. Highest performance, lowest latency, most features. Used by Solace's native SDKs for Java, C, C#, JavaScript, and others.
  • MQTT 3.1.1 and 5.0: Full MQTT broker, including QoS 0, 1, and 2, retained messages, and last will and testament. Useful for IoT device connectivity.
  • AMQP 1.0: The OASIS standard messaging protocol. Interoperates with any AMQP 1.0 client library.
  • REST: Simple HTTP POST for producing messages and webhooks for consuming them. Not the highest performance, but universally accessible.
  • JMS 1.1 and 2.0: Full JMS provider implementation. Drop-in replacement for ActiveMQ, IBM MQ, or TIBCO EMS for Java applications.
  • WebSocket: For browser-based messaging applications, often used with the JavaScript SDK.

All of these protocols can operate simultaneously on a single broker instance. An MQTT IoT device can publish a temperature reading to sensors/building-7/floor-3/temperature, and a JMS Java application subscribed to sensors/building-7/> will receive it seamlessly. The broker handles protocol translation internally.

This multi-protocol capability is not a superficial feature. Many enterprise environments have decades of messaging infrastructure across multiple technologies: legacy JMS applications, modern microservices, IoT devices, partner integrations over REST. Solace can genuinely serve as a single broker that speaks all of these protocols, replacing multiple dedicated systems with one platform.

Whether you want to concentrate that much messaging infrastructure into a single vendor is a reasonable question. But the capability is real.

Event Mesh and Dynamic Message Routing

The Event Mesh Concept

Solace's "event mesh" is the company's most ambitious architectural concept and its primary differentiation from other brokers. An event mesh is a network of interconnected PubSub+ brokers spanning multiple data centres, clouds, and edge locations. Messages published to any broker in the mesh are automatically routed to any other broker where there are matching subscriptions.

The idea is compelling: a global, multi-cloud messaging fabric where applications publish and subscribe to topics without caring about where other applications are running. A service in AWS publishing to orders/region/EMEA/new has its messages automatically delivered to a subscriber running on-premises in Frankfurt, without the publisher or subscriber knowing or caring about the routing path.

Dynamic Message Routing (DMR)

The mechanism that makes this work is Dynamic Message Routing. When a broker in the mesh receives a client subscription, it propagates that subscription to neighbouring brokers. When a message matching that subscription is published on any broker in the mesh, the message is forwarded hop-by-hop through the mesh to the broker where the subscriber is connected.

DMR is "dynamic" because:

  • Subscription propagation is automatic — no manual configuration of message bridges or forwarding rules
  • Routes are established and torn down as clients connect and disconnect
  • The mesh adapts to topology changes (broker additions, removals, failures)

This is a genuine differentiator. Building equivalent functionality with Kafka requires MirrorMaker 2 or Confluent Cluster Linking, both of which are topic-level replication tools rather than subscription-aware routing. With Solace, you do not replicate entire topics between clusters; you route individual messages based on actual consumer interest. This is more efficient for scenarios where only a subset of messages in a topic are needed at a remote site.

The event mesh concept is powerful but comes with caveats:

  • Latency: Inter-broker message forwarding adds latency proportional to the number of hops and the network distance between brokers. A message routed from Singapore to London through Frankfurt involves real physics.
  • Complexity: Debugging message routing in a multi-site mesh is harder than debugging a single broker. "Why did this message not arrive?" becomes "Which broker in the mesh was supposed to route it, and did the subscription propagate correctly?"
  • Vendor lock-in: An event mesh is inherently a Solace-to-Solace technology. You are building your global messaging architecture around a single vendor's product. If that vendor's pricing changes, or your technical needs diverge from their roadmap, extraction is painful.

Strengths

Genuine Multi-Protocol Support

Not a half-baked MQTT bolt-on or a JMS compatibility shim. Solace's protocol support is native, tested, and complete. If you have a heterogeneous environment — and most enterprises do — this eliminates an entire category of integration headaches.

The Event Mesh Vision

For organisations operating across multiple clouds and data centres, the event mesh concept is genuinely ahead of the competition. No other broker offers comparable built-in multi-site, subscription-aware message routing. Whether you need it is one question. Whether anyone else offers it as a first-class feature is not — they do not.

Enterprise Feature Set

Access control, Message VPNs, rate limiting, quota management, audit logging, LDAP integration, redundancy groups, monitoring APIs — Solace has the full complement of features that enterprise procurement and security teams require. These are features that you build yourself (poorly) on top of Kafka, or buy through Confluent's enterprise tier. Solace includes them in the platform.

Hardware Appliance Option

For ultra-low-latency use cases where software brokers — no matter how well optimised — introduce unacceptable jitter, the hardware appliance option is unique in the market. FPGA-based message routing with deterministic sub-microsecond latency is a capability you simply cannot get from software. If you need it, you need it, and Solace is the only mainstream vendor that offers it.

Consistent Low Latency

Even the software broker, written in C/C++ without JVM overhead, delivers consistent low-latency performance. The absence of garbage collection pauses means latency distributions are tighter than JVM-based brokers, which matters for P99 and P99.9 SLAs.

Weaknesses

Proprietary Core Protocol

SMF is Solace's native protocol and the one that delivers the best performance and most complete feature set. It is proprietary. Using SMF means using Solace's SDKs, which means coupling your application code to Solace's libraries. You can use AMQP or MQTT to reduce this coupling, but you lose features and potentially performance in the process.

This is the fundamental tension with Solace: the best experience is the most proprietary experience. The standards-based experience is available but second-tier.

Pricing Opacity

Solace does not publish pricing for its Enterprise or Mission Critical tiers. The cloud service has published pricing, but the self-managed software broker pricing requires "contact sales." In an industry that has moved toward transparent, publicly listed pricing (Confluent, AWS, most SaaS products), this is an irritant that suggests the price is either high, highly variable, or both.

If you are an enterprise with a procurement team, this is business as usual. If you are a startup trying to evaluate total cost of ownership, the lack of transparent pricing is a significant obstacle to even beginning the evaluation.

Smaller Community

Compare the size of the Kafka, RabbitMQ, or even NATS community — Stack Overflow questions, blog posts, conference talks, third-party tools, open-source integrations — with Solace's community, and the difference is stark. This matters practically: when you hit an obscure problem at 2 AM, the probability of finding a relevant Stack Overflow answer or blog post is much lower for Solace than for Kafka.

Solace has a community portal, documentation, and sample code. Their documentation is actually quite good. But the volume of community-generated knowledge is a fraction of what the open-source brokers enjoy.

Vendor Dependency

If you build your architecture around Solace's event mesh, Message VPNs, and SMF protocol, you are deeply coupled to a single vendor. More deeply than using Kafka (which has Redpanda, multiple managed offerings, and an open protocol) or RabbitMQ (which is open source). This is not necessarily fatal — plenty of enterprises run on proprietary infrastructure successfully — but it should be an eyes-open decision.

Scaling Model

The active-standby redundancy model does not scale horizontally for a single Message VPN's throughput the way Kafka's partition model does. You scale by distributing across an event mesh, which adds latency and complexity, or by vertical scaling. For workloads that require massive throughput at a single site, Kafka's horizontal partitioning model is more natural.

Ideal Use Cases

Large Enterprises with Multi-Protocol Needs

If your environment includes legacy JMS applications, modern microservices, IoT devices, and partner integrations over REST, Solace can genuinely serve as a single messaging platform. Replacing four different brokers with one — even a proprietary one — reduces operational burden, simplifies monitoring, and eliminates inter-broker bridges.

Hybrid Cloud and Multi-Cloud

The event mesh concept is purpose-built for organisations that operate across multiple clouds and on-premises data centres. If your architecture spans AWS, Azure, and an on-premises data centre, and you need messages to flow transparently between them, Solace offers this as a core capability rather than a bolted-on afterthought.

Financial Services

Solace's origins in financial services are evident in its feature set: low-latency messaging, guaranteed delivery, hardware appliance option for ultra-low-latency paths, Message VPN isolation for regulatory compartmentalisation. Banks and trading firms are a natural fit and represent a significant portion of Solace's customer base.

Event-Driven Architecture Consolidation

Enterprises that have accumulated multiple messaging systems over the years — IBM MQ here, ActiveMQ there, a Kafka cluster in the corner, an MQTT broker for IoT — and want to consolidate onto a single platform. Solace's protocol support makes gradual migration feasible: you can move applications one at a time without rewriting all of them simultaneously.

Operational Reality

PubSub+ Manager

PubSub+ Manager is the web-based management interface. It provides configuration management for Message VPNs, queues, topics, and client connections. The interface is enterprise-grade — comprehensive, if not beautiful. Compared to Kafka's "management is a CLI tool and some third-party web UIs" situation, PubSub+ Manager is a significant step up for day-to-day operations.

You can also manage everything through a RESTful management API (SEMP — Solace Element Management Protocol), which is well-documented and scriptable. Infrastructure-as-code through Terraform is supported via a Solace-maintained Terraform provider.

Monitoring

The broker exposes metrics through SEMP, and Solace provides integration with Prometheus, Grafana, Datadog, and Splunk. The metrics are comprehensive: message rates, queue depths, client connections, replication lag, and resource utilisation.

One area where Solace genuinely excels is in client-level visibility. You can see individual client connections, their subscription sets, message rates, and connection metadata. When debugging "why is consumer X not receiving messages?", this level of visibility is invaluable.

Cloud vs Self-Managed

PubSub+ Cloud is the managed service option and removes the operational burden of running brokers. It is available on AWS, Azure, and GCP. The service handles broker provisioning, redundancy, software updates, and monitoring. For teams that do not want to operate messaging infrastructure, this is the obvious choice.

Self-managed deployments give you more control over configuration, networking, and placement but require your team to handle broker lifecycle management, upgrades, and monitoring infrastructure. Solace provides Docker images, Kubernetes Helm charts, and VMware templates for deployment.

The Free Tier

PubSub+ Cloud's free tier and the free software broker edition deserve mention. The cloud free tier provides a single broker with limited capacity — sufficient for development, prototyping, and learning. The software broker's Standard edition is free for up to a generous connection and queue limit.

This lowers the barrier to evaluation significantly. You can deploy a PubSub+ broker in Docker, connect to it with multiple protocols, and evaluate the feature set without talking to a sales representative. The experience is smooth, the documentation is clear, and you can form a reasonable opinion of the platform without spending money. That said, production deployments will almost certainly require a paid tier, and that is where the "contact sales" pricing conversation begins.

Code Examples

Java (JCSMP — Solace's Native API)

import com.solacesystems.jcsmp.*;

public class SolaceProducerExample {

    public static void main(String[] args) throws JCSMPException {
        // Create session properties
        JCSMPProperties properties = new JCSMPProperties();
        properties.setProperty(JCSMPProperties.HOST, "tcp://localhost:55555");
        properties.setProperty(JCSMPProperties.VPN_NAME, "default");
        properties.setProperty(JCSMPProperties.USERNAME, "admin");
        properties.setProperty(JCSMPProperties.PASSWORD, "admin");

        // Create session
        JCSMPSession session = JCSMPFactory.onlyInstance()
            .createSession(properties);
        session.connect();

        // Create a producer (XMLMessageProducer)
        XMLMessageProducer producer = session.getMessageProducer(
            new JCSMPStreamingPublishCorrelatingEventHandler() {
                @Override
                public void responseReceivedEx(Object correlationKey) {
                    System.out.println("Message acknowledged: "
                        + correlationKey);
                }

                @Override
                public void handleErrorEx(Object correlationKey,
                        JCSMPException cause, long timestamp) {
                    System.err.println("Message failed: " + cause);
                }
            });

        // Create and send a persistent message
        Topic topic = JCSMPFactory.onlyInstance()
            .createTopic("orders/region/EMEA/currency/EUR");

        TextMessage message = JCSMPFactory.onlyInstance()
            .createMessage(TextMessage.class);
        message.setText("{\"type\":\"OrderPlaced\","
            + "\"orderId\":\"ord-7829\","
            + "\"amount\":149.99,"
            + "\"currency\":\"EUR\"}");
        message.setDeliveryMode(DeliveryMode.PERSISTENT);
        message.setCorrelationKey("ord-7829");

        producer.send(message, topic);
        System.out.println("Message sent to " + topic.getName());

        // Cleanup
        session.closeSession();
    }
}

import com.solacesystems.jcsmp.*;

public class SolaceConsumerExample {

    public static void main(String[] args) throws JCSMPException {
        JCSMPProperties properties = new JCSMPProperties();
        properties.setProperty(JCSMPProperties.HOST, "tcp://localhost:55555");
        properties.setProperty(JCSMPProperties.VPN_NAME, "default");
        properties.setProperty(JCSMPProperties.USERNAME, "admin");
        properties.setProperty(JCSMPProperties.PASSWORD, "admin");

        JCSMPSession session = JCSMPFactory.onlyInstance()
            .createSession(properties);
        session.connect();

        // Bind to a queue for guaranteed messaging
        Queue queue = JCSMPFactory.onlyInstance()
            .createQueue("orders-queue");

        ConsumerFlowProperties flowProperties =
            new ConsumerFlowProperties();
        flowProperties.setEndpoint(queue);
        flowProperties.setAckMode(JCSMPProperties.SUPPORTED_MESSAGE_ACK_CLIENT);

        FlowReceiver consumer = session.createFlow(
            new XMLMessageListener() {
                @Override
                public void onReceive(BytesXMLMessage message) {
                    if (message instanceof TextMessage) {
                        String text = ((TextMessage) message).getText();
                        System.out.println("Received: " + text);
                    }
                    // Acknowledge the message
                    message.ackMessage();
                }

                @Override
                public void onException(JCSMPException exception) {
                    System.err.println("Consumer error: " + exception);
                }
            },
            flowProperties
        );

        consumer.start();
        System.out.println("Consumer listening on " + queue.getName());

        // Keep running
        try {
            Thread.sleep(Long.MAX_VALUE);
        } catch (InterruptedException e) {
            consumer.close();
            session.closeSession();
        }
    }
}

The JCSMP API is verbose in a way that will feel familiar to anyone who has worked with JMS or other enterprise Java messaging APIs. It is not pretty, but it is explicit about what is happening. Every connection property, delivery mode, and acknowledgement behaviour is visible in the code, which is a feature when you are debugging production issues at 3 AM.

Python (solace-pubsubplus)

import solace.messaging
from solace.messaging.messaging_service import MessagingService
from solace.messaging.config.transport_security_strategy import TLS
from solace.messaging.resources.topic import Topic
from solace.messaging.publisher.persistent_message_publisher import (
    PersistentMessagePublisher
)

# Configure the messaging service
broker_props = {
    "solace.messaging.transport.host": "tcp://localhost:55555",
    "solace.messaging.service.vpn-name": "default",
    "solace.messaging.authentication.scheme.basic.username": "admin",
    "solace.messaging.authentication.scheme.basic.password": "admin",
}

messaging_service = MessagingService.builder() \
    .from_properties(broker_props) \
    .build()

messaging_service.connect()

# Create a persistent publisher
publisher = messaging_service \
    .create_persistent_message_publisher_builder() \
    .build()
publisher.start()

# Publish a message
topic = Topic.of("orders/region/EMEA/currency/EUR")
message_body = '{"type":"OrderPlaced","orderId":"ord-7829"}'

outbound_message = messaging_service.message_builder() \
    .with_application_message_id("ord-7829") \
    .build(message_body)

publisher.publish(outbound_message, topic)
print(f"Message published to {topic}")

# Cleanup
publisher.terminate()
messaging_service.disconnect()

from solace.messaging.messaging_service import MessagingService
from solace.messaging.resources.queue import Queue
from solace.messaging.receiver.persistent_message_receiver import (
    PersistentMessageReceiver
)

broker_props = {
    "solace.messaging.transport.host": "tcp://localhost:55555",
    "solace.messaging.service.vpn-name": "default",
    "solace.messaging.authentication.scheme.basic.username": "admin",
    "solace.messaging.authentication.scheme.basic.password": "admin",
}

messaging_service = MessagingService.builder() \
    .from_properties(broker_props) \
    .build()

messaging_service.connect()

# Create a persistent receiver bound to a queue
queue = Queue.durable_exclusive_queue("orders-queue")

receiver = messaging_service \
    .create_persistent_message_receiver_builder() \
    .build(queue)
receiver.start()

print("Consumer listening...")

# Blocking receive loop
while True:
    message = receiver.receive_message(timeout=5000)
    if message is not None:
        payload = message.get_payload_as_string()
        print(f"Received: {payload}")
        receiver.ack(message)

The Python SDK is more modern than the Java JCSMP API — builder pattern, cleaner naming — but still carries the weight of enterprise messaging abstractions. It is not as terse as a NATS or Redis client, but it exposes the full capabilities of the broker.

REST Producer

# Publish a message via REST
# This works with any HTTP client — no SDK required

curl -X POST \
  "http://localhost:9000/orders/region/EMEA/currency/EUR" \
  -H "Content-Type: application/json" \
  -H "Solace-Delivery-Mode: persistent" \
  -d '{"type":"OrderPlaced","orderId":"ord-7829","amount":149.99}'

The REST interface is Solace's secret weapon for quick integrations. Any system that can make an HTTP POST can publish messages to Solace. No SDK, no library dependency, no protocol-specific knowledge required. The URL path maps to the topic hierarchy. For webhook-style integrations and systems written in languages without a Solace SDK, this is invaluable.

The trade-off is performance and feature completeness. REST is HTTP, which means TCP connection overhead, HTTP header overhead, and no persistent session state. For high-throughput producers, the native SDK over SMF is orders of magnitude more efficient. For low-volume integrations and quick scripts, REST is perfect.

Verdict

Solace PubSub+ is a genuinely capable messaging platform that suffers primarily from being in the wrong narrative at the wrong time. The industry's attention has been captured by open-source, developer-community-driven projects — Kafka, NATS, RabbitMQ — and Solace's enterprise-first, sales-driven go-to-market does not generate blog posts, conference talks, or Twitter enthusiasm. This is a marketing problem, not a technology problem.

The technology is solid. Multi-protocol support is best-in-class. The event mesh concept is architecturally sound and genuinely ahead of the competition. The hardware appliance option is unique. The operational tooling is mature. For the right use case — large enterprise, multi-protocol environment, hybrid cloud, financial services — Solace is a strong choice that solves real problems that other brokers either cannot solve or solve only with significant additional effort.

The concerns are equally real. Vendor lock-in with SMF is meaningful. Pricing opacity is frustrating. The smaller community means less collective knowledge and fewer third-party integrations. The active-standby scaling model is less flexible than Kafka's horizontal partitioning. And building your global messaging architecture around a single commercial vendor requires a level of trust in that vendor's long-term viability and pricing stability.

The practical recommendation:

  1. If you are a large enterprise with existing multi-protocol messaging infrastructure and you need to consolidate or extend it across clouds, Solace deserves a serious evaluation. It may be the only platform that can genuinely replace multiple brokers with one.

  2. If you are building a new system on a single cloud provider, your cloud provider's native messaging services (SQS/SNS, Google Pub/Sub, Azure Event Hubs) are probably simpler and cheaper. Solace adds value when you span multiple environments.

  3. If you are a startup or small team, Solace is likely overkill. The free tier is great for learning, but the enterprise feature set is designed for enterprise problems. Use NATS or RabbitMQ and revisit when your problems are enterprise-scale.

  4. If you need the hardware appliance for ultra-low-latency, there is no alternative in the managed broker space. Solace or a custom-built solution are your options.

Solace PubSub+ is the answer to "I need one messaging platform that speaks every protocol, runs everywhere, and has enterprise governance built in." If that is your question, Solace is likely the best answer available. If that is not your question, there are simpler, cheaper, more community-supported options. Know your question before evaluating the answer.