One of the most frequent questions customers ask me is “What is the difference between a queue vs. a topic endpoint?”. While both queues and topic endpoints persist messages, it’s important to understand what they are, how they’re different, and when each one should be used.

Introduction to Solace Endpoints

Solace endpoints are objects created on the event broker to persist messages. There are two types of endpoints: queue endpoints (usually just called queues) and topic endpoints.

Topic Endpoints vs Topics

Before we talk about queues vs. topic endpoints, it’s important to note that a topic endpoint is not the same thing as a topic. Topics are a message property the event broker uses to route messages to their destination, and they aren’t administratively configured on the event broker. Topic endpoints, on the other hand, are objects that define the storage of messages for a consuming application, and they do need to be provisioned on the event broker. Topic endpoints are more closely related to queues than to topics, as confusing as that can seem at first.

Common Characteristics of All Endpoints

Before we compare queues and topic endpoints, let’s take a high-level look at endpoints in general:

Topic Subscriptions : A consuming application uses subscriptions to route messages towards it. Solace endpoints can have topic subscriptions applied to attract messages to the endpoint where a consuming application receives the messages from.

A consuming application uses subscriptions to route messages towards it. Solace endpoints can have topic subscriptions applied to attract messages to the endpoint where a consuming application receives the messages from. Selectors: A conditional statement applied to an endpoint by a consuming application to filter messages by their header and user properties.

A conditional statement applied to an endpoint by a consuming application to filter messages by their header and user properties. Queue Browsing: A consuming applications’ ability to read messages from a queue without removing them from the queue.

Queue vs. Topic Endpoints

Sending by Name: A producing application has the option to send a message directly to a queue by referencing that queue by its name in the message properties. A producing application cannot, however, reference topic endpoints by name, and therefore only persist messages routed to the topic subscription applied to the topic endpoint.

A producing application has the option to send a message directly to a queue by referencing that queue by its name in the message properties. A producing application cannot, however, reference topic endpoints by name, and therefore only persist messages routed to the topic subscription applied to the topic endpoint. Support for Multiple Topic Subscriptions: Queues support multiple topic subscriptions. This allows for topic aggregation to a single consuming application. Topic endpoints support a single subscription; should that subscription change, all messages persisted to the topic endpoint are deleted. Messages persisted in queues are unaffected by subscription changes.

Queues support multiple topic subscriptions. This allows for topic aggregation to a single consuming application. Topic endpoints support a single subscription; should that subscription change, all messages persisted to the topic endpoint are deleted. Messages persisted in queues are unaffected by subscription changes. Application of Selectors: Selectors can be applied to either type of endpoint to apply conditional logic, but the two endpoints differ in when the conditional is processed. With queues, selectors are processed at egress, and with topic endpoints they are processed on ingress. This means that queues persist every message even if they don’t match the selector, while with topic endpoints messages are only persisted if they match both the topic subscription and the selector.

Selectors can be applied to either type of endpoint to apply conditional logic, but the two endpoints differ in when the conditional is processed. With queues, selectors are processed at egress, and with topic endpoints they are processed on ingress. This means that queues persist every message even if they don’t match the selector, while with topic endpoints messages are only persisted if they match both the topic subscription and the selector. Support for Multiple Consumers: Queues support multiple consumers, providing a fault tolerant option should a consuming application disconnect from the queue. Exclusive topic endpoints support a single consumer, matching the functionality of a JMS durable subscription. Non-exclusive topic endpoints can support multiple consumers for load balancing purposes.

Queues support multiple consumers, providing a fault tolerant option should a consuming application disconnect from the queue. Exclusive topic endpoints support a single consumer, matching the functionality of a JMS durable subscription. Non-exclusive topic endpoints can support multiple consumers for load balancing purposes. Ability to Read Without Removal: Finally, a queue can be read from without removing messages, whereas topic endpoints require the removal of messages to be read.

Which endpoint should you use?

With all of that said, lets look at the question of queue vs. topic endpoint. Queues are used more often because of their support for more subscriptions, more consumers, and the ability to read without removal which is very handy for troubleshooting and special processing.

Topic endpoints may be better if you want to apply selector processing sooner to filter messages and not necessarily save them to the endpoint. Also, note that topic endpoints were originally created to support durable subscriptions in JMS, and is the only option for JMS durable subscribers.

I hope this post has helped you understand the matter of queue vs topic endpoint. If you found this post useful, visit the endpoints section of our docs, and our PubSub+ for Developers page for more information. If you have any questions about queues and topic endpoints, try posting them to the Solace Developer Community.