Trigger choice, concurrency, and failure paths decided deliberately
Azure Service Bus
RabbitMQKafka
DockerOut-of-order shipment status updates were eliminated, the downstream partner API stopped being rate-limited by burst scale-out, and every function app now has a consistent, documented failure path.
Overview
An Azure Functions estate is only as sound as its trigger design. Service Bus versus Event Hubs versus Storage Queues is a decision about ordering, throughput, and delivery semantics — and per-function concurrency settings are what stop a scaling function app from flattening whatever it calls.
Challenge
Trigger selection had been made case by case with no documented reasoning. Ordering-sensitive shipment events ran on a trigger with no session support, so status updates could be applied out of order. Default host concurrency settings let a function app scale out hard enough to exhaust a downstream API's rate limit. Poison message handling existed on some functions and not others, so failures were sometimes silently discarded.
Environment
Azure Functions integrating Service Bus, event streams, and external partner APIs, alongside self-hosted messaging infrastructure. AceMQ designs the customer's event architecture; Microsoft operates the platform.
Approach
AceMQ mapped each event flow's ordering, throughput, and delivery requirements onto a specific trigger type with documented reasoning, then set host-level and per-function concurrency to match downstream capacity. Because the estate spans both cloud messaging and self-hosted brokers, we designed the boundaries between them explicitly rather than letting them blur.
Solution
- 1Matched each event flow to a trigger type based on ordering, throughput, and delivery guarantees
- 2Adopted session-enabled messaging for shipment flows that require per-entity ordering
- 3Set host and per-function concurrency limits sized to downstream API and database capacity
- 4Standardized poison message handling and dead-letter inspection across all function apps
- 5Defined the boundary and bridging pattern between cloud messaging and self-hosted brokers
- 6Established idempotency and correlation ID conventions so retries and tracing work consistently
Outcome
Out-of-order shipment status updates were eliminated, the downstream partner API stopped being rate-limited by burst scale-out, and every function app now has a consistent, documented failure path.
Technologies
Azure Service BusRabbitMQKafkaDockerRelated Use Cases
Azure Functions Cost and Scaling Assessment
Reviewing hosting plan choice, instance scaling behavior, and cold start impact across an Azure Functions estate to align cost with actual workload shape.
Azure Durable Functions Orchestration Support
Recovering Durable Functions orchestrations stuck mid-flight because non-deterministic orchestrator code broke replay after a deployment.
AWS Lambda Event-Source Architecture Consulting
Designing event-source mapping, batching, ordering, and failure handling for a Lambda estate that had grown without a consistent event architecture.
Azure Functions Storage Account Trigger Failure Remediation
Diagnosing functions that silently stopped triggering after a storage account connectivity change — a dependency the runtime has but the application code never mentions.
Spring Framework and RabbitMQ Integration for IoT Security Platforms
AceMQ supports security technology companies using Spring Framework with RabbitMQ for IoT messaging, providing expertise across the Spring–RabbitMQ integration layer and commercial support for both technologies under a single engagement.
RabbitMQ Support for Online Gaming Platform
Enterprise messaging support for one of the world's largest online gaming software providers.
Need Azure Functions Architecture Guidance?
AceMQ's senior Azure Functions engineers have handled this exact type of engagement before. Whether you need architectural guidance, hands-on remediation, or an ongoing managed partnership, we're ready to help.