Grids, Hubs, & Buses... Oh My!




Azure Storage Queues, Azure Event Hubs, Azure Event Grids, and Azure Service Bus have many similar traits and functionality, but their differences make them unique to specific use cases.  I find that I have to familiarize myself often with their respective functionalities and how we can use these services.

Azure Messaging services are popular architecture choices with use cases such as Microservice Communications, Event-Driven Architectures, and Real-Time Telemetry based applications.  This blog post depicts some of the areas I will analyze when making an architecture decision around messaging or events in Azure.

The table below from Microsoft Learn is a very general depiction of when to use a specific messaging service in Azure.  Microsoft Learn is always my first stop when looking for  documentation around Azure and resources within.

Unfortunately, it never can be this simple and the "devil is in the details"   There are always other technical and business factors to ensure the solution aligns with your application's requirements.   Below are some other considerations I factor in my architecture decisions.


Communication Patterns
The communication patterns determine how messages and/or events move between senders and receivers.     A point-to-point communication between producers and consumers requires a message-based solution and is supported by both Azure Service Bus and Azure Queue Storage.

Event-Driven applications will broadcast events from one source to many subscribers.  This publish-subscribe architecture is supported by Azure Event Grid and Azure Event Hubs.

Data streaming and real-time processing of high-volume data streams will be supported by Azure Event Hubs.

Message Ordering
Many event-driven applications we build require messages or events to be processed in the correct sequence.  It is often that application workflow and business logic have dependencies between steps and preserving order is essential.  Real time analytics, transaction and batch processing all require that we preserve order of our events and messages 

Azure Service Bus and Event Hubs ensure message sequence or  relations via message sessions and partitions respectively.    Azure Queue Storage or Azure Event Grid does not guarantee any ordering.

Performance
There are multiple factors including speed, scalability, message size, throughput, and reliability that relate to performance around Azure Messaging and Event services.

Throughput refers to the number of messages or events being processes.  Applications with higher message volumes require a services with no bottlenecks.
    • Azure Storage Queue supports moderate throughput for simple workloads
    • Azure Service Bus is for medium to high throughput
    • Azure Event Hubs is designed for high-throughput workloads (i.e. millions of events per second)
Latency refers to the time taken for a message to travel from sender to receiver.   This metric is critical for real-time applications (i.e. chat systems, live dashboard, or streaming analytics).
    • Azure Event Grid is very low latency (i.e. milliseconds) 
    • Azure Service Bus has moderate latency
    • Azure Storage Queue has higher levels of latency
Message Size refers to the maximum payload size of service.  This characteristic has determined my architectural decision multiple times.
    • Azure Storage Queue support up to 64Kb
    • Azure Service Bus support 256Kb or 1Mb Premium Tier
    • Azure Event Hub support 1Mb per event
Scalability is the services capacity to handle increasing workloads and ensures that your application is responsive under heavy loads.
    • Azure Event Hubs scale horizontally with "partitions"
    • Azure Event Grid automatically scales
    • Azure Service Bus can scale with using the Premiums tiers and partitioned entries
Reliability metric is how we ensure that messages are delivered without being lost.   This metric is critical for application.
    • Azure Service Bus has "at-least-once" delivery, deduplication, and dead-lettering for guaranteed delivery.
    • Azure Event Grid ensures "at-lead-once" delivery with retries
    • Azure Queue Storage offers "at-least-once" delivery without deduplication functionality.
Understanding your applications requirements and the specific functional characteristics of Azure Message and Event services are key to making  the best architectural decisions and ensuring you have selected the best messaging or event service for your scenario.  Please let me know if you would like more information or would like to explore your specific messaging and event architectures.

This post does not touch on Azure Notification Hubs or Azure SignalR services... I will leave these for a later blog post...!