Why use queue?
In programming, especially in the era of microservices, we encounter situations when we need to process more data than we can handle in one moment. In such a situation, we can stop receiving new data until we finish processing the current one, or we just add each next piece of data to the collection and continue processing it one by one. We can do it sequentially or use multiple threads and then things will go faster. Actually, it doesn’t matter how much data we need to process, we just pick one element from the collection and process it, then pick the next one. This is very intuitive. We can see examples of such processes everywhere in real life.
In programming, such type of collection is called a
Queue. Some
Danish engineer and mathematician even created a
Queueing theory, which could be very useful when we need to design complex systems.
How skillfully developer is able to use collections, and especially queues, to solve problems, defines his level of competence.
Queues and messaging
In case of a simple in-memory queue, adding and popping items from the queue is not a big deal. But if we already have more sophisticated architecture, consisting of more than one service and we need to guarantee that the queue doesn’t disappear on server restart, then delivering new items in the queue requires an advanced interface. A messaging system could act as such an interface. With messaging systems, apart from simple functionality such as adding and popping items from the queue, you get additional benefits such as delivery guarantee, durability, routing and more. Often these two concepts - queue and messaging - are used together or even interchangeably.
Event and Message
We can distinguish different types of items in queue depending on their purpose and content.
It is important to understand what kinds of items you will use, because it will determine the type of the queue and messaging system.
Event - this is just a notification. It just says “Hello! Something happened.” Producer of the event doesn’t care about what the consumer does with it. Also, don’t care when the event processed. Their task is just to notify.
Typically, an event contains information about what happened. For example, a user changes his status from ‘online’ to ‘offline’, the event could contain the user’s id, status, and time of change. If a particular event is part of a bigger change, it could contain some unique identifier of change, to make it possible to connect separate events to the big picture.
Events are delivered in the same order they were received. This fact is important, especially if it’s logs or bank transactions.
Message - this is a command. It says “Please do this for me.” A message has specific consumer and precise action to do. For example: “Add a new user”. It should contain all the required information to complete the task. Producer of the command has an expectation of how and when the command will be handled. For example, it could expect a notification when the user is added.
However, there are scenarios where a producer doesn’t expect any response from a consumer. For example, if a message is used to pass the data to the next step in some processing flow.
Queue in the cloud
Nowadays Azure platform offers many queue messaging services. You may be asking why a single platform offers so many services for queue and messaging. Each solution has a slightly different set of features and, depending on your needs and the problem you are solving, you can choose the most suitable. In this article, I will briefly cover three most popular products: Azure Queue, Service Bus, and Event Grid. I hope it will help you to choose a proper solution which best meets your needs.
Azure Queue is a simple queue and messaging service. It is built on top of Azure Storage. This is the first queue service introduced in the Azure platform.
What is good about this product:
- Big single queue size, limited only by the Storage quota, up to 500 TB;
- At-Least-Once delivery guarantee;
- RESTful and HTTP/HTTPS interfaces;
- Client library for .NET, as well as for other languages: Java, PHP,
Node.js;
- Detailed logs and aggregated metrics are available out of the box.
What you need to consider:
- It doesn’t guarantee FIFO order;
- It doesn’t support publish/subscribe and routing;
- There are no transactions;
- Long-polling is not supported, so there is no instant delivery.
Ideal for simple scenarios where you need reliable messaging between application components, to leverage load or build process workflow.
Due to lack of publish/subscribe model and FIFO order guarantee, it’s more suitable to deal with “messages” rather than “events”.
It’s worth to mention the
Azure storage emulator, which could be very useful in testing and development. What is more, in Visual Studio it’s possible to manage the queues, view, add and update messages (in Server Explorer).
Azure Service Bus is a more sophisticated solution, which would satisfy the most demanding cases. It’s like a Swiss Army Knife.
What is good about this product:
- Thanks to a TCP-based full-duplex protocol, long polling is available and hence “almost immediate delivery”;
- At-Least-Once and At-Most-Once delivery guarantee;
- Duplicate detection;
- FIFO order guaranteed within session;
- Transactions and atomicity for many messages;
- Publish/Subscribe model;
- Messages routing and filtering.
What you need to consider:
- No out-of-the-box detailed logs;
- No emulator;
- No build-in Visual Studio explorer/browser tool;
- 80 GB limit per queue;
- In higher tiers and big numbers of messages, it could be quite costly.
It could be used for critical features like processing banking transactions, orders, bookings, etc. Also, thanks to long polling, it could be useful in applications like chats or messengers.
Thanks to a wide range of features Service Bus could be configured to deal with “messages” as well as with “events”.
Please see the
detailed comparison of Azure Queue and Azure Service Bus.
Event Grid: This service uses the Publish/Subscribe model. It’s intended to work with big amount of emitted “events”, not correlated with each other. So it’s not designed to process sequences of events (streams) but rather separate, independent events. Many subscribers could consume events simultaneously, depending on context or filtering rules.
What is good about this product:
- Deeply integrated with the Azure infrastructure, so it’s easy to integrate with other Azure services, such as serverless applications or other queues.
- At-Least-Once delivery guarantee.
- Pay-per-event.
- Designed with a focus on a great scale.
- Advanced filtering and routing.
What you need to consider:
- No back-pressure so event consumers should be prepared for high load and protect themselves from crashing.
Summary
This article is a brief introduction to a broader concept of the infrastructure of Azure Messaging. I recommend exploring other message-driven services like Event Hub. It’s also worthwhile to understand how to make the Azure services work together, using such products like Logic Apps, Notification Hub or Azure Function.
