Contact Us

Contact Us

How to Boost App Efficiency with Microsoft Azure Async Options

Asynchronous Processing Options with Microsoft Azure Services

Efficiency is key in the digital landscape. At Technosoft, we were recently tasked with improving the performance of a client’s application. The app was expected to cater to over 500 concurrent users, but the app was only able to handle a maximum of ~60 simultaneous users. After the initial review and adjustments, we increased the maximum number of concurrent users to 100, but this was still below the required level. The application load was usually received in a burst; thus, simple synchronous tasks would clog the processor under load. We opted to offload some of the tasks to an asynchronous queue as a solution.

We explored different options under the Microsoft Azure services umbrella, and the following blog reviews these options in detail. 

Online Transaction-Oriented Processes In Azure Asynchronous Services

The article focuses on improving app performance using various asynchronous processing options. This involves optimizing backend processes to handle a high volume of transactions efficiently and securely.

Synchronous vs. Asynchronous Processing

Synchronous Processing: It refers to the execution of programming tasks sequentially. While this is simpler to implement, from a programming point of view, it is only sometimes the most efficient approach for all scenarios, especially when a high usage level is expected.

Asynchronous Processing: Moving towards asynchronous processing allows the system to handle tasks independently. This means that while one task is waiting for a response, another task can be executed. This improves scalability and responsiveness. Asynchronous processing can be achieved by writing multi-threaded applications. It can also be achieved by implementing a queueing service. Multi-threaded applications tend to stay within the same processor space. Thus, if the same processor is under heavy load by the primary process, other threads executed within the same processor would also provide a slow response. Therefore, delegating tasks to a queue helps reduce the load from the processor of the primary process.

HIPAA Compliance

Ensuring HIPAA-compliant processes is paramount when dealing with sensitive healthcare information. We audit the systems to guarantee that asynchronous processes and data storage solutions adhere to these regulations.

Below is a comparative analysis of Microsoft Azure services for asynchronous online transaction processing.

Microsoft Azure Async Queue Storage

Azure Queue Storage provides a messaging queue for inter-process communication and enables asynchronous message processing. It allows the decoupling of components in a system, facilitating the efficient handling of a high volume of transactions.


You need to pay only for storage and transactions, making it ideal for high-volume, low-complexity scenarios:

  • Storage: Pay per GB stored, with different tiers like LRS (locally redundant storage) and RA-GRS (read-access geo-redundant storage) offering various redundancy levels.
Storage Cost for Microsoft Azure Queue Storage
Cost for Microsoft Azure Queue Storage
  • Transactions: Pay per transaction (enqueue, dequeue, peek, etc.).
Transactions Cost for Azure Queue Storage Option
Transactions Cost for Azure Queue Storage Option

Pricing support in the context of supporting 1000 users with Azure Queue storage is as follows:

Base price: $500

Additional charge per user: $0.05


  • Simple and lightweight: Easy to implement and integrate with your applications.
  • Highly scalable: Handles large volumes of messages with automatic scaling of queue size.
  • Durable and reliable: Messages are replicated across multiple storage nodes for high availability and fault tolerance.
  • Flexible delivery semantics: Offers “At-Least-Once” delivery, meaning each message may be delivered one or more times.


  • No guaranteed delivery: Individual messages may be lost due to network issues or application errors.
  • Limited message size: A maximum message size of 64 KB can be insufficient for complex data structures.
  • Basic messaging patterns: Supports only FIFO (First-In, First-Out) ordering, hindering implementation of advanced messaging patterns like publish-subscribe.
  • No server-side processing: Requires separate infrastructure for processing messages outside the queue.

Use Cases

  • For simple, high-volume messaging with basic FIFO ordering.
  • When absolute message delivery guarantee is not critical.
  • To prioritize cost-effectiveness for large numbers of messages.

Microsoft Azure Service Bus 

Azure Service Bus is a fully managed enterprise integration message broker with broad capabilities for reliable messaging between applications and services. It facilitates asynchronous communication, message queuing, and publish-subscribe messaging scenarios, offering a reliable and secure platform for building scalable and decoupled applications.


Service Bus costs more than Queue Storage due to its advanced features and server-side processing functionalities. Costing models are as follows:

  • Tier-based pricing: Offers Basic, Standard, and Premium tiers with varying message size limits, throughput, and features.
Azure Tier-based pricing for Service bus
Azure Tier-based pricing for Service bus
  • Pay per unit: You pay for messages sent, received, and stored, along with other usage metrics based on your chosen tier.
Pay per unit Cost for Service bus
Pay per unit Cost for Service bus


Pricing support in the context of supporting 1000 users with Azure Service Bus would depend on the chosen tier and the volume of messages sent, received, and stored.

When estimating the total cost, it’s important to consider the message size, througout, and other usage metrics.

For example, if you anticipate a certain message volume per user, you can calculate the total cost as follows:

Total Cost=Cost per Unit×Total Units Consumed per Month


  • The cost per unit is determined by the selected tier (Basic, Standard, Premium).
  • The total units consumed per month include sending, receiving, and storing messages.

To determine the Total Units Consumed per Month, we need to estimate the message volume sent, received, and stored per month for 1000 users. Let’s denote:

  • as the total number of messages sent and received per user per month.
  • as the average size of each message in KB.
  • as the average number of days each message is stored.

Then, the total units consumed per month can be calculated as:


  • Guaranteed delivery: Offers “At-Most-Once” and “Exactly-Once” delivery guarantees depending on the chosen messaging pattern.
  • Rich messaging patterns: Supports patterns like publish-subscribe, topics, and durable subscriptions for flexible message routing and consumption.
  • Server-side processing: Integrates with Azure Functions for server-less message processing within the queueing infrastructure.
  • Advanced features: Message sessions, dead-lettering, retry mechanisms, and advanced security options provide robust messaging capabilities.
    • Message Sessions: A message session in Azure Service Bus allows you to handle unbounded sequences of related messages in a joint and ordered manner.
    • Dead-lettering: Dead-lettering in Azure Service Bus is like a second chance for problematic messages. It moves undelivered or un-processable messages from the regular queue or topic to a dedicated “dead-letter queue” (DLQ) and retries delivery.


  • Complex setup and configuration:  It requires more effort to set up and manage compared to Queue Storage.
  • Not ideal for very high-volume, simple scenarios:  It may be excessive for basic queuing requirements that prioritize cost-effectiveness.

Use Cases

  • For complex messaging scenarios requiring guaranteed delivery and advanced patterns.
  • When rich features and server-side processing are necessary.

For applications with diverse messaging needs and integration requirements.

Microsoft Azure’s asynchronous Event Grid

Azure Event Grid is a fully managed event routing service that simplifies event-based programming. It provides reliable event delivery at a massive scale and enables reactive and decoupled system architectures.


Pay per event published and delivered, free tiers available for low-volume usage.

  • Tier-based pricing
Tier-based pricing For Azure Event Grid
Tier-based pricing For Azure Event Grid


Pricing support for 1000 users would depend on the number of events generated and delivered within the specified period.

The total cost can be estimated based on the selected tier and the expected event volume.


  • The cost per event is published based on the chosen tier (Basic, Standard, Premium).
  • The total number of events published per month by all users.
  • The cost per event delivered is based on the chosen tier.
  • The total number of events delivered per month is assumed to be equal to the total events published per month in Azure Event Grid.

To determine the Total Events Published per Month, we need to estimate the event volume published per month for 1000 users.


  • Serverless and event-driven: Simplifies event publishing and routing without managing queues.
  • Deep Azure integration: Triggers Azure Functions, Logic Apps, and other services directly from events.
  • Flexible event routing: Filters and distributes events based on custom rules and subscriptions.
  • Global reach: Delivers events across regions with built-in scalability.


  • Not a traditional queue: Not suitable for message storage or complex processing workflows.
  • Limited delivery guarantees: Relies on downstream services for delivery guarantees.
  • Not ideal for long-lived message scenarios: Events are short-lived and do not persist for extended periods.

Use Cases

  • For event-driven architectures with server-less event routing.
  • When simplicity and fast event delivery are the essential requirements.
  • To trigger other Azure services and workflows seamlessly.


Adopting asynchronous processing presents challenges, including error handling and tracking task completion. However, the efficiency, scalability, and user experience benefits are substantial and align with our goals for growth and improved service delivery.

Technosoft facilitates HIPAA-compliant integration of Microsoft Azure, such as Queue storage, Service Bus, and Event grid services, into healthcare systems to enable the handling of bulk online transactions.

These services are utilized for asynchronous messaging, real-time event handling, and communication between healthcare applications and systems. Contact us to discuss how we can improve the performance of your healthcare system or efficiently help integrate with other systems.

Starting any Healthcare Integration Project? Get Your questions answered in a Free 30 minutes consultancy!