Solace Kafka Integration: Bridging, the Wireline Proxy and Connectors

Solace Kafka integration exists because most enterprises that buy an event broker already run Kafka, and the two do different jobs. Solace offers three mechanisms to connect them: Kafka bridging built into the event broker (a Kafka Receiver and a Kafka Sender), the open-source Kafka wireline proxy that lets Kafka clients talk to Solace directly, and connectors, meaning the Kafka Connect source and sink connectors or Solace Micro-Integrations for Kafka. The limit to know first: Solace documents in-broker bridging as supported “only on software event brokers, and not appliance event brokers” (Kafka bridging).

This page explains each mechanism, when it fits, and what goes wrong. It belongs under Solace protocols and APIs in the Solace cluster.

Why integrate Solace and Kafka at all

Kafka is a distributed log: consumers pull, retention is long, and replay into analytics and stream processing is the point. Solace routes events by hierarchical topic, pushes them to consumers over many protocols, and links brokers across sites into an event mesh. Solace’s own comparison recommends a hybrid in which Kafka handles log retention and analytics and Solace handles distribution (Solace vs Kafka). That is a vendor view, but it matches the pattern we see in plants: MQTT and operational events at the edge, Kafka in the data platform. The full comparison is on Solace vs Kafka.

Since IBM completed its acquisition of Confluent in March 2026, some buyers also want the integration layer to stay vendor-neutral, which is another reason to keep it explicit and documented.

The three Solace Kafka mechanisms

1. Kafka bridging inside the broker

Bridging configures two objects on the broker, and “message flow is possible in both directions” (Kafka bridging):

• Kafka Receiver reads records from one or more Kafka topics, converts them to SMF messages and publishes them to Solace topics. The Solace topic is built with substitution expressions, for example replacing Kafka’s . separators with / so plant1.line3.oee becomes plant1/line3/oee.
• Kafka Sender takes messages from one or more Solace queues, converts them to Kafka records and sends them to Kafka topics. The Kafka topic is “a single fixed value per queue binding”.

Fits when you run software brokers and want no extra moving parts. Does not fit on appliances, and Solace Cloud support is not stated on the page we read.

2. The Kafka wireline proxy

The Kafka wireline proxy, introduced in September 2025, presents a Kafka broker facade and translates to SMF, so Kafka clients connect “without changing a single line of application code”. Solace lists key-based partitioning, schema registry, headers, three acknowledgement modes and consumer groups. It is open source in SolaceLabs and runs on Kubernetes, Docker or as a standalone JAR.

Fits when Kafka-native applications should publish into or consume from the Solace mesh directly, without a Kafka cluster in between.

3. Connectors and Micro-Integrations

The older route is the open-source Kafka Connect source and sink connectors, which run in a Kafka Connect cluster. The newer one is Solace Micro-Integrations, launched in December 2024 with targets including Apache Kafka, Confluent, Redpanda, Amazon MSK and Azure Event Hubs (launch release), available cloud-managed or self-managed.

Fits when the Kafka team already runs Kafka Connect, when you need a managed Kafka service as the target, or when the broker is an appliance.

Choosing a Solace Kafka mechanism

	Kafka bridging	Wireline proxy	Connectors / Micro-Integrations
Runs	Inside the broker	Separate process	Kafka Connect or Micro-Integration runtime
Broker form factor	Software only (appliance excluded)	Any, per its design	Any
Direction	Both	Kafka clients into Solace	Source, sink or both
Application change	None	Kafka client configuration	None
Operated by	Broker team	Integration team	Kafka or integration team
Support	Product feature	Open source in SolaceLabs; ask	Product (Micro-Integrations) or open source (Connect)

A rule of thumb. If you run software brokers, start with bridging. If you run appliances or a managed Kafka service, use Micro-Integrations. Use the proxy when the goal is to remove a Kafka cluster that only exists to feed Solace, and test it hard first. Event Portal can discover Kafka topics and consumer groups through its Event Management Agent, which helps decide what to bridge.

Designing a Solace Kafka bridge

Whichever mechanism you choose, the design questions are the same, and they are easier to answer before the first topic moves:

1. List the consumers in Kafka, not the producers in the plant. Bridge the topics a named analytics or data team will use. Everything else stays in Solace, where it costs nothing to leave.
2. Agree the topic and key mapping. Decide how Solace levels become Kafka topic names and which field becomes the Kafka record key, since the key drives partitioning and ordering downstream.
3. Decide the direction per flow. Plant events usually go Solace to Kafka. Model results or setpoint recommendations may come back the other way, and those need the same governance as any write to a plant system.
4. Size the buffer. The Kafka Sender reads from Solace queues, so a Kafka outage fills those queues. Set quotas and alerts that give the operations team hours, not minutes.
5. Register the schemas. Payload formats should be documented on both sides. Solace’s Schema Registry and Event Portal, or the Kafka team’s registry, both work; having none does not.

An illustrative case. A manufacturer with six plants publishes line states, downtime reasons and quality results over MQTT into Solace brokers at each site, linked by an event mesh to a software broker in the corporate data centre. The data team wants a year of downtime history in Kafka for a reliability model. A Kafka Sender on the central broker reads one queue subscribed to */*/*/downtime/> and writes to a single Kafka topic, keyed by line. The plants never learn Kafka exists, and the data team never connects to a plant network. That separation is also a security boundary, which our OT network assessment work treats as seriously as the data flow.

Where it gets hard

• Two delivery models. Kafka consumers track offsets; Solace acknowledges per message. Duplicates appear at the boundary after failures, so consumers must be idempotent.
• Ordering. Kafka orders within a partition, Solace within a queue. Keep keys stable, and look at partitioned queues where ordering per key matters.
• Topic naming. Dotted Kafka names and /-separated Solace levels need one agreed mapping.
• Fixed Sender topics. One Kafka topic per queue binding means more bindings as topics multiply.
• Monitoring two systems. Queue depth on the Solace side and consumer lag on the Kafka side describe the same backlog. Put both on one dashboard, or each team will blame the other.
• Message size and rate. Check the limits on both sides for your largest payloads and peak bursts.

Related: Kafka vs MQTT for the concepts, the sibling Solace MQTT page, and the Solace hub.