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.
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.