Azure Service Bus
Tags: webdev, cloud, azure, beginners
Published: 2024-03-16 13:18:05

Azure Service Bus is a cloud-based messaging service that facilitates communication between applications and services without requiring everything to be in the cloud. At its core is the Azure Service Bus Namespace, which serves as a container for organizing messaging components. Within a single namespace, you can have multiple queues and topics, helping to manage and streamline communication.

Service Bus is ideal for enterprise-level messaging where critical business information, such as invoices, financial transactions, or credit card swipes, needs to be reliably transmitted. Its key features ensure that messages are,

- delivered in sequence 
- maintain integrity during sessions
- support transactional operations, 

making it crucial for operations where accuracy and order are paramount.


![azure service bus](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/i0g6o5b84q8m1ktghiej.png)


Azure Service Bus offers comprehensive integration with various Azure services, enhancing its functionality and application scope. Key services that integrate well with Service Bus include Event Grid, Logic Apps, Functions, Dynamics 365, and Stream Analytics. The integration with Event Grid, in particular, enables connectivity with numerous other services, expanding its utility. Moreover, Service Bus provides a straightforward API, facilitating easy interaction with these diverse Azure services

**Queue** 

- Messages are sent to and received from queues, simplifying the communication process.
- Queues allow for the temporary storage of messages until the receiving application is available to process them.
- Messages in the queue are organized and timestamped upon arrival, ensuring an orderly sequence.
- Once a message is accepted, it is stored in redundant storage to prevent loss.
- The delivery mechanism is based on pull mode, requiring the receiving application to request messages actively.


![Queue processing](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7y4m6u014ah8chzwdla4.png)




**Topics and Subscriptions**

- Topics and Subscriptions are used for asynchronous message sending and receiving, similar to queues but with distinct capabilities.
- While queues support point-to-point communication, topics are ideal for publish/subscribe (pub/sub) scenarios.
- A single topic can have multiple, independent subscriptions, enhancing message distribution flexibility.
- Subscribers can receive all messages sent to a topic or use rules and filters to receive specific messages, allowing targeted communication.
- Topics enable distributing a single message to multiple receivers, which is not typically possible with queues.
- Azure Service Bus incorporates various advanced features, demonstrating its robustness as a messaging technology.
- It integrates seamlessly with other Azure services, extending its utility and application within the Azure ecosystem.


![Topics and Subscriptions processing](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/2wym04t34qqd31z4oapm.png)

**Azure Service Bus and Azure Storage Queues**

Azure Storage Queues are very similar to Azure Service Bus, Comparison is down below.


|**Feature** |**Azure Service Bus**|**Azure Storage Queues**|
| :- | :- | :- |
|**Intended Use**|Complex enterprise-level messaging|Simple, high-volume messaging|
|**Messaging Features**|Advanced (e.g., dead-lettering, duplicate detection, sessions, transactions)|Basic|
|**Communication Patterns**|Supports various patterns (e.g., pub/sub, sessions)|Basic queuing|
|**Integration**|Extensive with Azure services|Limited|
|**Protocols and Standards**|AMQP, SBMP, HTTP/HTTPS|HTTP/HTTPS|
|**Security**|Advanced security and compliance|Basic security|
|**Scalability**|Highly scalable with more complex features|Highly scalable with simpler features|
|**Message Size and TTL**|Up to 256 KB/message, configurable TTL|Up to 64 KB (256 KB for premium), max 7 days TTL|
|**Cost**|Up to 256 KB/message, configurable TTL|More cost-effective for basic needs|
|**Ideal for**|Enterprise applications requiring reliable, ordered, and complex messaging|Web-scale applications requiring massive volume processing with less complexity|



Azure Service Bus supports various messaging patterns that allow the distribution of messages to multiple consumers. Some of these patterns include:

- **Publish/Subscribe (Pub/Sub):** 
  - This is the primary pattern used to distribute a message to multiple consumers. A publisher sends messages to a topic, and each message is then forwarded to all subscriptions associated with that topic. Each subscription acts like an independent queue, receiving copies of the messages sent to the topic. This way, multiple consumers (subscribers) can independently retrieve and process the messages.
- **Competing Consumers**: 
  - In this pattern, multiple consumers connect to the same queue or subscription. Each consumer competes for message processing. Once a consumer retrieves a message for processing, it is locked and becomes invisible to other consumers. This pattern is useful for load balancing and increasing throughput, as different consumers process different messages in parallel.
- **Forwarding**: 
  - Azure Service Bus allows you to automatically forward messages from a queue or subscription to another queue or topic. This feature can be used to create complex routing schemes or workflows where messages processed by one consumer are automatically sent to another queue or topic for further processing by additional consumers.
- **Sessions**: 
  - When dealing with ordered message processing, sessions allow related messages to be processed sequentially. In a scenario with multiple consumers, each session (identified by a session ID) ensures that all messages within a session are processed by the same consumer, maintaining message order within each session.
- **Dead-lettering:** 
  - While not a direct method of distributing messages to multiple consumers, dead-letter queues can be used as part of a broader pattern where messages that cannot be processed (e.g., due to format errors or processing failures) are moved to a dead-letter queue. These messages can then be consumed and handled (e.g., investigated or reprocessed) by a separate set of consumers.