AZ-305 Practice Question 9: Messaging Architecture Choice
Microsoft Azure Solutions Architect Expert (AZ-305) · Test 1 · question 9 of 10
An insurance company is decomposing its claims engine into microservices. The messaging layer between the intake service and the adjudication workers must satisfy four constraints drawn from an audit finding:
- All messages belonging to the same claim ID must be processed strictly in the order they were sent, even when several workers are running. - If the intake service retries a send after a timeout, the broker itself must discard the repeat rather than creating a duplicate claim. - A message that repeatedly fails adjudication must be moved aside for manual inspection without blocking the messages behind it. - Completing an inbound message and publishing the resulting outbound message must happen as a single atomic operation.
Which messaging service should the architecture use?
Show answer and explanation
Answer:
Service Bus is the enterprise transactional messaging broker in the Azure messaging family, and it is the only one of these services that offers all four features natively. Sessions give FIFO ordering within a session while different sessions are still processed in parallel by different workers, which is exactly "in order per claim, but scaled out". Duplicate detection makes the broker drop a resend carrying a message ID it has already seen inside the configured window. The dead-letter subqueue holds messages that exceed the max delivery count, out of the way of the live queue. And Service Bus supports transactions, so a complete and a send can be committed together.
Option A is a streaming service, not a broker. Event Hubs guarantees ordering only per partition, but it has no duplicate detection, no dead-lettering, and no transactions. It is built for high-volume telemetry ingestion and replay, not for per-entity workflow state.
Option B fails three of the four. Event Grid is for reactive routing of discrete event notifications: it offers dead-lettering, but it provides no ordering guarantee, no duplicate detection, and no transactions.
Option D pushes the platform's job into the application. Queue Storage has no session-based ordering, no server-side duplicate detection, and no transaction support; the poison-message counter in the option is application code compensating for a missing broker feature, and it still cannot deliver ordering or atomicity.
Reference: Choose between Azure messaging services