Case study

Fabrikam Logistics — order and telemetry platform

Fabrikam Logistics runs an order platform on Azure Container Apps, split into an order API, a billing worker, and a notification service.

When an order is placed the API must write the order to its database and publish an OrderPlaced event. Billing must process the events for a given customer strictly in the order they were raised, because a later amendment may reverse an earlier charge. Billing is idempotent by design but has been observed to charge twice during redeploys.

Separately, 250,000 delivery vehicles emit GPS and sensor telemetry every 5 seconds. Two independent teams consume this stream: the live tracking map, and an analytics job that must be able to reprocess the previous three days after a model change.

The notification service calls a third-party SMS gateway that is rate limited to 10 requests per second and returns HTTP 429 beyond it. During promotional bursts the notification service has been overwhelming the gateway.

Requirements

No order may be published without its database write succeeding
Per-customer ordering for billing events
Exactly-once financial effect despite at-least-once delivery
Two independent consumers of the telemetry stream, with 3-day replay
Respect the downstream 10 requests/second SMS limit

Q43 Service Bus Domain 3 · 20–25% of exam Priority · Real Exam

Billing must process each customer's events strictly in order. What is required?

A Enable sessions and set SessionId to the customer id (correct answer)
B Increase MaxDeliveryCount
C Use a single consumer with no concurrency
D Enable partitioning on the queue

Shortcut: Sessions bind all messages with the same SessionId to one consumer holding an exclusive lock, which is what preserves FIFO per customer while still allowing many customers to be processed in parallel. A single global consumer would also preserve order but destroys throughput.

Billing must process each customer's events strictly in order. What is required?

More Service Bus questions