Design Patterns

Azure Messaging Patterns

This blog explores key messaging design patterns used in distributed systems architecture. These patterns help improve scalability, reliability, and performance in cloud-native applications.

Pattern Description Well-Architected Pillars
Asynchronous Request-Reply Decouples back-end processing from front-end, allowing async operations with a clear response. Performance Efficiency
Claim Check Splits large messages into a lightweight reference and a payload stored externally. Reliability, Security, Cost Optimization, Performance Efficiency
Competing Consumers Multiple consumers process messages from the same queue concurrently to improve throughput. Reliability, Cost Optimization, Performance Efficiency
Messaging Bridge Enables communication between incompatible messaging systems via an intermediary. Cost Optimization, Operational Excellence
Priority Queue Ensures high-priority messages are processed faster than others. Reliability, Performance Efficiency
Publisher/Subscriber Broadcasts events to multiple consumers asynchronously without tight coupling. Reliability, Security, Cost Optimization, Operational Excellence, Performance Efficiency
Queue-Based Load Leveling Buffers requests using a queue to handle load spikes smoothly. Reliability, Cost Optimization, Performance Efficiency
Sequential Convoy Processes related messages in order without blocking unrelated message groups. Reliability

These patterns are foundational for building robust cloud applications. For more, explore the full Azure Architecture Center.

Azure, Azure Integration Services

Azure Logic Apps & Service Bus: When Do You Need the ‘Manage’ Claim?

Ever wondered why your Azure Logic Apps sometimes fail to process messages consistently from a Service Bus queue? If you’ve run into issues with scaling, missing permissions, or unexpected failures, you’re not alone.

One of the key reasons for these inconsistencies is whether runtime scaling is enabled or disabled. And a major factor that affects this is the ‘Manage’ claim in your Service Bus connection string.

Understanding the Role of Runtime Scaling

Azure Functions that process messages from Service Bus queues can scale dynamically based on queue length. This is controlled by runtime scale monitoring. Whether you need the ‘Manage’ claim depends on whether this setting is enabled or not.

When Runtime Scaling is Enabled – ‘Manage’ Claim is Required

  • When runtime scaling is ON, Azure needs to check the active message count to decide whether to scale up.
  • To get this information, the system queries the Service Bus queue metadata.
  • Without the Manage claim in the connection string, the system cannot access queue details and fails to determine the active message count.

And that’s when you start seeing errors like this:

“Connection string does not have ‘Manage Claim’ for queue ‘[Queue_Name_Here]‘. Unable to determine active message count.”

Since it can’t retrieve the queue length, it falls back on alternative metrics:

“Failed to get queue description to derive queue length metrics. Falling back to using first message enqueued time.”

When Runtime Scaling is Disabled – ‘Manage’ Claim is NOT Required

  • When runtime scaling is OFF, Azure Functions do not need to query the queue length.
  • The function still processes messages as they arrive, but without automatic scaling.
  • Since it doesn’t check queue metadata, the Manage claim is not needed.

This is why, in some cases, disabling runtime scaling makes things appear to work more reliably. There’s no interference from scaling decisions, and messages just get processed at a steady rate.

How to Avoid Failures and Keep Things Running Smoothly

If You Want Scaling (Runtime Scaling ON)

  • ✅ Make sure your Service Bus connection string has the Manage permission.
  • ✅ Enable runtime scale monitoring in Azure Function settings.
  • ✅ Keep an eye on scaling behavior in Application Insights to avoid thread pool starvation.

If You Don’t Need Scaling (Runtime Scaling OFF)

  • ✅ No need for the ‘Manage’ claim—just Listen and Send permissions are enough.
  • ✅ Adjust function concurrency settings to control the processing rate manually.
  • ✅ Monitor your Service Bus queue to ensure messages don’t pile up.

By understanding how runtime scaling and permissions interact, you can avoid frustrating failures and keep your Azure Logic Apps running smoothly. Whether you need scaling or just steady processing, configuring things the right way makes all the difference.