You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/service-bus-messaging/service-bus-queues-topics-subscriptions.md
+64-35Lines changed: 64 additions & 35 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,20 +11,36 @@ ms.date: 01/31/2026
11
11
12
12
Azure Service Bus supports reliable message queuing and durable publish/subscribe messaging. The messaging entities that form the core of the messaging capabilities in Service Bus are **queues**, **topics and subscriptions**.
13
13
14
+
This article explains these core messaging entities, their benefits, and when to use each one in your application architecture.
15
+
14
16
> [!IMPORTANT]
15
-
> If you are new to Azure Service Bus, read through [What is Azure Service Bus?](service-bus-messaging-overview.md) before going through this article.
17
+
> If you're new to Azure Service Bus, read through [Introduction to Azure Service Bus](service-bus-messaging-overview.md) before going through this article.
18
+
19
+
## Choose between queues and topics
20
+
21
+
The following table summarizes the key differences between queues and topics to help you choose the right messaging entity for your scenario.
|**Filtering**| Not supported | Subscription filters for selective message delivery |
16
29
17
30
## Queues
18
31
19
32
Queues offer **First In, First Out** (FIFO) message delivery to one or more competing consumers. That is, receivers typically receive and process messages in the order in which they were added to the queue. And, only one message consumer receives and processes each message.
20
33
21
-
:::image type="content" source="./media/service-bus-messaging-overview/about-service-bus-queue.png" alt-text="Image showing how Service Queues work.":::
22
-
23
-
A key benefit of using queues is to achieve **temporal decoupling of application components**. In other words, the producers (senders) and consumers (receivers) don't have to send and receive messages at the same time, because messages are stored durably in the queue. Furthermore, the producer doesn't have to wait for a reply from the consumer to continue to process and send messages.
34
+
:::image type="content" source="./media/service-bus-messaging-overview/about-service-bus-queue.png" alt-text="Diagram of a Service Bus queue showing messages flowing from senders to the queue and then to receivers.":::
24
35
25
-
A related benefit is **load-leveling**, which enables producers and consumers to send and receive messages at different rates. In many applications, the system load varies over time. However, the processing time required for each unit of work is typically constant. Intermediating message producers and consumers with a queue means that the consuming application only has to be able to handle average load instead of peak load. The depth of the queue grows and contracts as the incoming load varies. This capability directly saves money regarding the amount of infrastructure required to service the application load. As the load increases, more worker processes can be added to read from the queue. Each message is processed by only one of the worker processes. Furthermore, this pull-based load balancing allows for best use of the worker computers even if the worker computers with processing power pull messages at their own maximum rate. This pattern is often termed the **competing consumer** pattern.
36
+
### Benefits of using queues
26
37
27
-
Using queues to intermediate between message producers and consumers provides an inherent loose coupling between the components. Because producers and consumers aren't aware of each other, a consumer can be **upgraded** without having any effect on the producer.
38
+
| Benefit | Description |
39
+
|---------|-------------|
40
+
|**Temporal decoupling**| Producers (senders) and consumers (receivers) don't have to send and receive messages at the same time, because messages are stored durably in the queue. The producer doesn't have to wait for a reply from the consumer to continue processing. |
41
+
|**Load leveling**| Producers and consumers can send and receive messages at different rates. The consuming application only needs to handle average load instead of peak load, saving infrastructure costs. |
42
+
|**Competing consumers**| Multiple worker processes can read from the queue, with each message processed by only one worker. This pull-based load balancing allows workers to process at their own maximum rate. |
43
+
|**Loose coupling**| Because producers and consumers aren't aware of each other, a consumer can be upgraded without affecting the producer. |
28
44
29
45
### Create queues
30
46
@@ -33,87 +49,100 @@ You can create queues using one of the following options:
You can specify two different modes in which consumers can receive messages from Service Bus.
48
64
49
-
-**Receive and delete**. In this mode, when Service Bus receives the request from the consumer, it marks the message as being consumed and returns it to the consumer application. This mode is the simplest model. It works best for scenarios in which the application can tolerate not processing a message if a failure occurs. To understand this scenario, consider a scenario in which the consumer issues the receive request and then crashes before processing it. As Service Bus marks the message as consumed, the application begins consuming messages upon restart. It will miss the message that it consumed before the crash. This process is often called **at-most once** processing.
50
-
-**Peek lock**. In this mode, the receive operation becomes two-stage, which makes it possible to support applications that can't tolerate missing messages.
51
-
1. Finds the next message to be consumed, **locks** it to prevent other consumers from receiving it, and then, return the message to the application.
52
-
1. After the application finishes processing the message, it requests the Service Bus service to complete the second stage of the receive process. Then, the service **marks the message as consumed**.
65
+
#### Receive and delete mode
66
+
67
+
When Service Bus receives the request from the consumer, it marks the message as consumed and returns it to the consumer application. This mode is the simplest model and works best for scenarios where the application can tolerate not processing a message if a failure occurs.
68
+
69
+
If the consumer crashes before processing the message, the message is lost because Service Bus already marked it as consumed. This process is often called **at-most once** processing.
70
+
71
+
#### Peek lock mode
72
+
73
+
The Receive operation becomes two-stage, which makes it possible to support applications that can't tolerate missing messages:
53
74
54
-
If the application is unable to process the message for some reason, it can request the Service Bus service to **abandon** the message. Service Bus **unlocks** the message and makes it available to be received again, either by the same consumer or by another competing consumer. Secondly, there's a **timeout** associated with the lock. If the application fails to process the message before the lock timeout expires, Service Bus unlocks the message and makes it available to be received again.
75
+
1. Finds the next message to be consumed, **locks** it to prevent other consumers from receiving it, and then returns the message to the application.
76
+
1. After the application finishes processing the message, it requests the Service Bus service to complete the second stage of the receive process. Then, the service **marks the message as consumed**.
55
77
56
-
If the application crashes after it processes the message, but before it requests the Service Bus service to complete the message, Service Bus redelivers the message to the application when it restarts. This process is often called **at-least once** processing. That is, each message is processed at least once. However, in certain situations the same message might be redelivered. If your scenario can't tolerate duplicate processing, add extra logic in your application to detect duplicates. For more information, see [Duplicate detection](duplicate-detection.md), which is known as **exactly once** processing.
78
+
**Handling failures in peek lock mode:**
57
79
58
-
> [!NOTE]
59
-
> For more information about these two modes, see [Settling receive operations](message-transfers-locks-settlement.md#settling-receive-operations).
80
+
-**Abandon**: If the application can't process the message, it can request Service Bus to **abandon** the message. Service Bus unlocks the message and makes it available to be received again.
81
+
-**Lock timeout**: If the application fails to process the message before the lock timeout expires, Service Bus unlocks the message and makes it available to be received again.
82
+
-**Application crash**: If the application crashes after processing the message but before completing it, Service Bus redelivers the message when the application restarts. This process is often called **at-least once** processing.
83
+
84
+
If your scenario can't tolerate duplicate processing, add extra logic in your application to detect duplicates. For more information, see [Duplicate detection](duplicate-detection.md), which is known as **exactly once** processing.
85
+
86
+
> [!NOTE]
87
+
> For more information about these two modes, see [Settling receive operations](message-transfers-locks-settlement.md#settling-receive-operations).
60
88
61
89
## Topics and subscriptions
62
90
63
91
A queue allows processing of a message by a single consumer. In contrast to queues, topics and subscriptions provide a one-to-many form of communication in a **publish and subscribe** pattern. It's useful for scaling to large numbers of recipients. Each published message is made available to each subscription registered with the topic. Publisher sends a message to a topic and one or more subscribers receive a copy of the message.
64
92
65
-
:::image type="content" source="./media/service-bus-messaging-overview/about-service-bus-topic.png" alt-text="Image showing a Service Bus topic with three subscriptions.":::
93
+
:::image type="content" source="./media/service-bus-messaging-overview/about-service-bus-topic.png" alt-text="Diagram of a Service Bus topic with three subscriptions receiving copies of messages.":::
66
94
67
95
Publishers send messages to a topic in the same way that they send messages to a queue. But, consumers don't receive messages directly from the topic. Instead, consumers receive messages from subscriptions of the topic. A topic subscription resembles a virtual queue that receives copies of the messages that are sent to the topic. Consumers receive messages from a subscription identically to the way they receive messages from a queue. The message-sending functionality of a queue maps directly to a topic and its message-receiving functionality maps to a subscription. Among other things, this feature means that subscriptions support the same patterns described earlier in this section regarding queues: competing consumer, temporal decoupling, load leveling, and load balancing.
68
96
69
-
Subscriptions can define which messages they want to receive from a topic. These messages are specified in the form of one or more named subscription rules. Each rule consists of a **filter condition** that selects particular messages, and **optionally** contain an **action** that annotates the selected message. By default, a subscription to a topic receives all messages sent to the topic. The subscription has an initial default rule with a true filter that enables all messages to be selected into the subscription. The default rule has no associated action. You can define filters with rules and actions on a subscription so that the subscription receives only a subset of messages sent to the topic.
97
+
### Subscription filters
70
98
71
-
For more details about filters, [Filters and actions](topic-filters.md).
99
+
Subscriptions can define which messages they want to receive from a topic. These messages are specified in the form of one or more named subscription rules. Each rule consists of a **filter condition** that selects particular messages, and **optionally** contains an **action** that annotates the selected message. By default, a subscription to a topic receives all messages sent to the topic. The subscription has an initial default rule with a true filter that enables all messages to be selected into the subscription. The default rule has no associated action. You can define filters with rules and actions on a subscription so that the subscription receives only a subset of messages sent to the topic.
100
+
101
+
For more information about filters, see [Filters and actions](topic-filters.md).
72
102
73
103
### Create topics and subscriptions
74
104
75
105
Creating a topic is similar to creating a queue, as described in the previous section. You can create topics and subscriptions using one of the following options:
In many scenarios, messages that have specific characteristics must be processed in different ways. To enable this processing, you can configure subscriptions to find messages that have desired properties and then perform certain modifications to those properties. While Service Bus subscriptions see all messages sent to the topic, it's possible to only copy a subset of those messages to the virtual subscription queue. This filtering is accomplished using subscription filters. Such modifications are called **filter actions**. When a subscription is created, you can supply a filter expression that operates on the properties of the message. The properties can be both the system properties (for example, **Label**) and custom application properties (for example, **StoreName**.) The SQL filter expression is optional in this case. Without a SQL filter expression, any filter action defined on a subscription is done on all the messages for that subscription.
121
+
In many scenarios, messages that have specific characteristics must be processed in different ways. To enable this processing, you can configure subscriptions to find messages with desired properties and then perform certain modifications to those properties. While Service Bus subscriptions see all messages sent to the topic, it's possible to only copy a subset of those messages to the virtual subscription queue. This filtering is accomplished using subscription filters. Such modifications are called **filter actions**. When a subscription is created, you can supply a filter expression that operates on the properties of the message. The properties can be both the system properties (for example, **Label**) and custom application properties (for example, **StoreName**.) The SQL filter expression is optional in this case. Without a SQL filter expression, any filter action defined on a subscription is done on all the messages for that subscription.
93
122
94
123
For a full working example, see the [TopicFilters sample](https://github.com/Azure/azure-sdk-for-net/tree/master/sdk/servicebus/Azure.Messaging.ServiceBus/samples/TopicFilters) on GitHub. For more information about filters, see [Topic filters and actions](topic-filters.md).
95
124
96
125
## Java message service (JMS) 2.0 entities
97
126
98
127
The following entities are accessible through the Java message service (JMS) 2.0 API.
99
128
100
-
* Temporary queues
101
-
* Temporary topics
102
-
* Shared durable subscriptions
103
-
* Unshared durable subscriptions
104
-
* Shared non-durable subscriptions
105
-
* Unshared non-durable subscriptions
129
+
- Temporary queues
130
+
- Temporary topics
131
+
- Shared durable subscriptions
132
+
- Unshared durable subscriptions
133
+
- Shared nondurable subscriptions
134
+
- Unshared nondurable subscriptions
106
135
107
136
Learn more about the [JMS 2.0 entities](java-message-service-20-entities.md) and about how to [use them](how-to-use-java-message-service-20.md).
108
137
109
-
## Express Entities
138
+
## Express entities
110
139
111
-
Express entities were created for high throughput and reduced latency scenarios. With express entities, if a message is sent to a queue or topic is, it is not immediately stored in the messaging store. Instead, the message is initially cached in memory. Messages that remain in the entity are written to the message store after a delay, at which point these are protected against loss due to an outage.
112
-
113
-
In regular entities, any runtime operation (like Send, Complete, Abandon, Deadletter) is persisted to the store first, and only after this is acknowledged to the client as successful. In express entities, a runtime operation is acknowledged to the client as successful first, and only later lazily persisted to the store. As a result, in case of a machine reboot or when a hardware issue occurs, some acknowledged runtime operations may not be persisted at all. This means the client gets lower latency and higher throughput with express entities, at the expense of potential data loss and/or redelivery of messages.
114
-
115
140
> [!IMPORTANT]
116
-
> Over time many optimizations have been done within Service Bus, meaning that the throughput and latency advantages of express entities are currently minimal. Moreover, the Premium tier of Service Bus does not support [Express entities](service-bus-premium-messaging.md#express-entities). Due to this, it is currently not recommended to use this feature.
141
+
> Express entities aren't recommended for new applications. The throughput and latency advantages are currently minimal due to optimizations in Service Bus. The Premium tier of Service Bus doesn't support [Express entities](service-bus-premium-messaging.md#express-entities).
142
+
143
+
Express entities were created for high throughput and reduced latency scenarios. With express entities, if a message is sent to a queue or topic, it isn't immediately stored in the messaging store. Instead, the message is initially cached in memory. Messages that remain in the entity are written to the message store after a delay, at which point they're protected against loss due to an outage.
144
+
145
+
In regular entities, any runtime operation (like `Send`, `Complete`, `Abandon`, `Deadletter`) is persisted to the store first, and only after the operation is acknowledged to the client as successful. In express entities, a runtime operation is acknowledged to the client as successful first, and only later lazily persisted to the store. As a result, when a machine reboots or when a hardware issue occurs, some acknowledged runtime operations might not be persisted at all. In this case, the client gets lower latency and higher throughput with express entities, at the expense of potential data loss and/or redelivery of messages.
0 commit comments