Trigger choice, concurrency, and failure paths decided deliberately

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

• Matched each event flow to a trigger type based on ordering, throughput, and delivery guarantees
• Adopted session-enabled messaging for shipment flows that require per-entity ordering
• Set host and per-function concurrency limits sized to downstream API and database capacity
• Standardized poison message handling and dead-letter inspection across all function apps
• Defined the boundary and bridging pattern between cloud messaging and self-hosted brokers
• Established idempotency and correlation ID conventions so retries and tracing work consistently

Outcome

Technologies