Are you developing an enterprise product? Need the right solution for communication between microservices? Looking for a way to improve the reliability and scalability of your application? Azure Service Bus might be the solution you are looking for.
Stay with us to find out!
What is it? And why should I use it?
Azure Service Bus is a highly reliable cloud messaging service. Service buses, in general, provide a solution for communication between services. Modern software starts to be created in microservice architecture more and more often. The need for a reliable communication solution is not a new thing, though. In the classical approach, one would use services like RabbitMQ, Mass Transit, or so to achieve this task.
What advantages does Azure Service Bus give, then? Besides many advanced features, which will be covered, it’s the availability. Advertised as dedicated to enterprise solutions, it’s one of the most mature products, which gets constant support for many years, used in many commercial projects. It grants disaster recovery, so even fire or flood won’t stop services from running. Being serverless PaaS, serverless solution frees the user from the need for installation and supporting local instances of the product, saving time and money, in the result. Everything can be configured in the Azure Portal with just a few clicks.
Quick Overview
There are two main ways Azure Service Bus can be used:
Queues
Queues let us implement First In, First Out (FIFO) communication between services. When using Queues for every message, there can be only one receiver type. Even if there are multiple instances of such service, only one of them will handle each sent message. Communication participants are named “message sender” and “message receiver”.
Sent messages are stored, even if the receiver is temporarily unavailable, and delivered later upon request (pull mode). Another advantage of using queues is the possibility of the sender and receiver to work with different frequencies. While messages can be sent very often, the receiver may choose to process them on its own rate to prevent crashes.
Topics
Topics can be used to send messages in publish-subscribe scenarios. Unlike in Queue, where each message always has only one type of receiver, topics can have multiple. Each subscriber gets their own copy of the message. There is a possibility to set rules that define which receiver can get which type of message so certain one can be sent to the wanted group of receivers only.
Which should I use?
If your applications are going to communicate with each other in one to one model, and your messages must always be delivered at all costs, use Queues. For example, for receiving many orders, which all must be processed.
If you need to broadcast messages to many systems that can react to the same message with different actions, use Topics. It can be used, for instance, to send notifications via many services (one service can provide SMS notifications, another — email, and so on). Topics are perfect for implementing microservice infrastructure where many services can react to a particular event.
Azure Service Bus — Advanced Features
Azure Service Bus has some advanced features that put it ahead of the competition. Let us list just some of them.
Dead-letter Queue
Azure Service Bus supports a queue of messages that cannot be delivered or processed where the operator can look into the issue, correct it, and resubmit the message.
Get-disaster recovery
When the entire region or datacenter of Azure experiences downtime, geo-disaster recovery allows data processing to continue on another region/data center.
Batching
Client-side batching enables a queue or topic client to delay sending a message for a specified period. If the client sends additional messages during this time, it transmits the messages in a single batch.
At least once / At most once delivery
Depending on the configuration of the Bus, a message can be processed in two ways. With “at least once” approach, if the application crashes while processing the message, it is delivered when the application restarts or is sent to another instance of the receiver if such exists. That guarantees, each message is processed at least once.
“At most once delivery” approach guarantees that once processed messages will never be received again, mitigating the risk of duplicating data (sending the same order twice or sending the same message multiple times).
We could go on and on with those features, but if you like to know more, you can always visit a page dedicated to Azure Service Bus and find out yourself.
How do we use it?
Do you want some real-life examples? Sure thing! We also use Azure Service Bus in our projects! Here are some use cases in which it comes in handy.
Sending emails with the order confirmation
User has placed their order. We have saved all necessary data in our database and now we want to send them an email with the order confirmation. Still, we don’t want them to wait until the service for notifications finishes its job, we want to show them nice “your order has been placed” as soon as possible. And what if the messaging service is down at the moment? Using Azure Service Bus, we don’t need to worry! The message will be sent after completing the request, and if it fails for any reason, it can be sent later.
Integration Events
If you are familiar with Domain-Driven Design in a microservice architecture, you probably know the term “integration event”. In short — integration event is some broadcasted message that might be of interest to third parties or services from other domains. Let’s not dive too deep into the DDD concept, for now, it’s left for reader’s research, and let’s focus on some particular cases.
All users’ orders should be stored, besides in our database, in the partner’s service. After an order has been placed, saved in our database, just before we notify the user about success, a message is sent to the Service Bus with details of the order. Partner’s service can subscribe to those types of messages and react with them in the desired way. If more services like that are added in the future, all requirements will include subscribing to the same message and handling it accordingly.
Conclusion
It’s worth mentioning that Service Bus is not the only one Azure messaging service. There are also Event Grid and Event Hubs, which all share some similarities but are designed for different scenarios. But that’s a story for a whole new article.
To wrap up Azure Service Bus is a solid enterprise solution to manage your communication between services with excellent scalability and reliability. It’s easy to create and maintain, and being popular software, users can find lots of solved problems and original usages online. Want to find out yourself? Then get on the Bus and try out! And if you are looking for a reliable business partner — let us know. We can work together on your software development product to achieve spectacular results.
