Ever wondered what the difference is between a Solace topic and an Apache Kafka topic? The short answer is… quite a lot. For an in-depth comparison, watch my full video. Or keep reading for a few key takeaways.

Before we get into the details, it helps to understand exactly what a “topic” is. Think of a topic as a concept of the publish-subscribe (pub/sub) architectural pattern. They are used to route data or events (in the form of messages) between distributed applications, often using a message broker or an event broker.

Typically, consuming applications register a topic subscription of interest with the broker. Whenever a publisher or producer sends a message on that topic, the broker forwards the message to any consumers that have a matching topic subscription. This promotes a loosely-coupled architecture, and provides a scalable, one-to-many style of communication.

Topic Implementation

Because topics are just concepts, their implementation and routing behavior is decided by specific brokers. Now, from an API perspective, Kafka and Solace APIs look pretty similar at first glance—both can subscribe and publish to a topic. However, one big difference is that consumers in Kafka need to poll to receive more messages, and in Solace consumers can follow a more event-driven design where messages are pushed to the application via a callback function.

A slide showing the differences between Kafka and Solace APIs

Kafka topics are implemented as log files, and because of this file-based approach, topics in Kafka are a very “broker-centric” concept. Messages on Kafka topics are sharded across partitions, and this can result in out-of-order messages across the whole topic, and can put a limit on the number of topics you can maintain in a Kafka broker.

With Solace, topics aren’t actually configured on the broker: they’re instead defined by the publishing application at publish time. They can be thought of as a property of a message, or metadata, and not like “writing to a file” or “sending to a destination.” Each and every message could be published with a unique topic.

Looking for some examples? At the 4:35 mark below I share few real-world use cases, one with a foreign exchange trading platform and another with a connected buses platform.

A slide showing examples of topics in Solace

Managing Topics on the Consumer Side

On the consumer side, when an application connects to Solace and specifies a topic subscription, it’s done in a very dynamic, real-time way. Solace forwards the message onto the clients on a message-by-message basis as they arrive at the broker, using essentially a subscription matching engine. Because of this, there’s a strong order guarantee on topics in Solace; if two clients/consumers are subscribed to the same topics, they will always receive messages in the exact same order.

But since published topics are so dynamic, how do we manage this from a subscription perspective? You can’t subscribe to an infinite number of topics! The answer: subscription wildcards.

Solace supports both multi-level > and single-level * prefix wildcards. Take a look at some examples at 7:20:

Examples of Solace Wildcard Descriptions

Solace’s hierarchical topic structure (multiple levels, delimited by slash /) and wildcard ability allows for much more fine-grained filtering at the broker than you may be able to get with a Kafka broker. Consumers only get the messages that they’ve subscribed to, versus having to filter at the receiving end.

Looking to dive deeper into the details? Definitely check out the whole video, and then connect with me here on LinkedIn if you have additional questions.

Check out our Solace vs Kafka page for a quick look at more differences between Apache Kafka and PubSub+ or read this interesting blog series:

  1. Solace PubSub+ vs Kafka: The Basics
  2. Solace PubSub+ vs Kafka: Implementation of the Publish-Subscribe Messaging Pattern
  3. Solace PubSub+ vs Kafka: Filtering
  4. Solace PubSub+ vs Kafka: High Availability
  5. Solace PubSub+ vs Kafka: Multi-Site Architecture

And for more details regarding operational use cases and why you need to look beyond Kafka, check out this other series:

Aaron Lee, Developer Advocate at Solace
Aaron Lee

Based in Singapore, Aaron is a developer advocate at Solace. He enjoys coding demos, making videos, running workshops – and writing blog posts when he must. He will happily discuss event-driven architecture, microservices networking protocols, application design, monitoring, time-series data, and visualization frameworks for as long as you’ll listen.

During his 10 years at Solace, he has worked as a pre-sales engineer and a professional services consultant around the globe, including time in Hong Kong, London, New York and his hometown of Ottawa. He has conducted lots of developer workshops to help folks better understand how to monitor event-driven systems powered by Solace infrastructure, and how to apply event-driven thinking to their programming and application design.

Aaron holds a master's degree in computer science and a bachelor's degree in mathematics, both from Carleton University, which makes hobbies like geometry and data visualizations make sense, along with the unexpected kite surfing and riding motorcycles.