A city permits API must accept large document-summarization jobs without making residents wait on the HTTP response. Which Azure messaging pattern should the back end use?
Select an answer to reveal the explanation.
Short Explanation
Think of the permits counter handing you a ticket and saying “we’ll call when it’s ready”—Service Bus is that ticket line so the API doesn’t make residents stand there while the AI summarizes a stack of PDFs.
Full Explanation
For municipal generative workloads such as permit-packet summarization, the public API should accept work asynchronously rather than keep a resident or clerk waiting on a long HTTP response. Azure Service Bus is the right pattern here: the permits API validates the request, enqueues a durable message that identifies the blob and job metadata, and returns quickly with a correlation or ticket id. A separate Container Apps or Functions worker then peeks or receives the message, runs the summarization model, and writes results back to storage or a status store the portal can poll. That decoupling keeps front-door capacity for other civic traffic while AI work runs for minutes.
Keeping the HTTP request open until every page is summarized fails on concept: gateway and App Service timeouts, connection limits, and poor horizontal scale all punish long-held requests, and a flaky client disconnect can lose progress with no durable handoff. Storing the PDF only in Blob Storage without notifying a worker also fails: blobs persist bytes but do not schedule compute; without Event Grid, a queue message, or another signal, no consumer knows work is waiting. Publishing exclusively to Event Grid without a durable queue is a weaker fit for long-running AI jobs: Event Grid is excellent for reactive notifications and fan-out, but it is not a work-buffer with competing consumers, lock renewal, and poison handling the way Service Bus is when summarization can take a long time and must survive retries.
Exam caveat: do not confuse “async accept” with “fire-and-forget without observability.” AI-200-style scenarios still expect status tracking, dead-letter paths for poison PDFs, and clear ownership of who consumes the queue. Operational check: confirm the API returns in well under a second after enqueue, that workers renew locks or complete before lock expiry during multi-page summarization, and that residents can look up job status by the correlation id without re-uploading the packet.