In many cloud scenarios, during a day, a service could have peaks of traffic (periods where the number of requests from sender applications is extremely high) and this could affect the performances of the entire architecture and of your business level.

To avoid these situations, a common architectural strategy is to use a queue that acts as a buffer of requests and permits you to decouple the sender from the receiver. Check this Microsoft diagram:

In this architecture, a sender, instead of directly sending a request to a cloud service, it sends a request to a message queue. Then, the cloud service retrieves the messages from the message queue and processes the request. What's important to note here is that the requests could arrive at the message queue with an extremely high volume, while the cloud service processes them at the desired rate. This ensures that the cloud service will never be busy or heavy load. The main advantages here are as follows:

• Reliability and availability: No messages are lost due to a failed request (timeout)
• Scalability: You can increase the number of queues or services according to your business needs

 Regarding the Azure platform, we can have two types of queue mechanisms:

• Azure Storage queues: Simple REST-based interface for message exchange between services (GET, PUT, PEEK). They are part of the Azure storage infrastructure. A queue message can be up to 64 KB in size and the number of messages is limited to the storage account capacity. The time-to-live (TTL) of a message is 7 days.
• Azure Service Bus: A more advanced mechanism that supports queues, topics, relays and message size up to 256 KB. The TTL of a message in a Service Bus queue can be unlimited. For more information, visit https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-fundamentals-hybrid-solutions.

Here, we'll show you how to use Azure Service Bus to implement a queue-based pattern:

1. In Azure portal, click on + and select Enterprise Integration | Service Bus:

2. In the Create namespace pane, give the name of your Service Bus queue and select resource group and location:

3. Now select the Queues option and add a new queue:

4. Select the queue name and set the queue parameters such as queue size and TTL:

5. Click Create and your Azure Service Bus queue will be provisioned and ready to be used (you can find the queue URL and the Shared Access policies option where you find the connection string):

6. When a client application sends a message to the queue, you can directly monitor the queue via the Azure portal itself:

From a C# application, you can use a queue in this way (the code extract comes from my book, Building ERP Solutions with Microsoft Dynamics NAV by Packt Publishing):

A client application sends a message (order object) to the Azure Service Bus queue:

var client = QueueClient.CreateFromConnectionString(ServiceBusConnectionString, QueueName);
BrokeredMessage message = new BrokeredMessage(order, new DataContractSerializer(typeof(ShopSalesOrder)));
client.Send(message);

The cloud service can retrieve the messages from the Azure Service Bus queue:

private static void ReceiveOrders()
        {
            Console.WriteLine("
Receiving message from Azure Service 
            Bus Queue…");
            try
            {
                var client = 
                QueueClient.CreateFromConnectionString
                (ServiceBusConnectionString, QueueName);
                while (true)
                {
                    try
                    {
                        //receive messages from Queue
                        BrokeredMessage message = 
                        client.Receive(TimeSpan.FromSeconds(5));
                        if (message != null)
                        {
                            //Retrieves the order object
                            Console.WriteLine(string.Format("Message 
                            received: Id = {0} ", message.MessageId));
                            ShopSalesOrder orderReceived = 
                            message.GetBody<ShopSalesOrder>(new 
                            DataContractSerializer(typeof
                            (ShopSalesOrder)));
                             //Further custom message processing could                       
                             go here…
                            message.Complete();
                        }
                        else
                        {
                            //no more messages in the queue
                            break;
                        }
                    }
                    catch (MessagingException e)
                    {
                        if (!e.IsTransient)
                        {
                            Console.WriteLine(e.Message);
                            throw;
                        }
                        else
                        {
                            HandleTransientErrors(e);
                        }
                    }
                }
            }
            catch(Exception ex)
            {
                //Handle exception here...
            }
        }