When a new ordinance PDF lands in Blob Storage, the city’s RAG indexer should start without polling. Which integration should they use?
Select an answer to reveal the explanation.
Short Explanation
Event Grid on blob create is the city’s doorbell—when the ordinance PDF hits storage, the RAG indexer gets a ping instead of pacing the hallway checking the mail slot.
Full Explanation
When a new ordinance PDF lands in Blob Storage, the city’s RAG indexer should react to the create event rather than poll. Azure Event Grid blob-created (and related Storage) events push that signal to a Function, Logic App, or webhook that starts chunking and embedding. The integration is event-driven: upload completes, Event Grid delivers, indexer runs—no busy loop against every container.
A continuous polling loop from App Service against every container every few seconds wastes compute, adds detection lag bounded by the poll interval, and scales poorly as ordinance libraries grow. Requiring clerks to email the AI team after each upload fails as automation: humans forget, messages get lost, and there is no durable retry contract. Using only Service Bus scheduled messages that ignore actual upload timing fails to bind work to reality: a schedule might run when nothing new arrived, or miss a midday upload until the next slot, whereas blob-created events fire on the upload itself.
Exam caveat: Event Grid notifies; it does not replace durable processing. Many municipal designs use Event Grid to enqueue a Service Bus message or trigger a Function that then performs the long RAG work. Also configure filters so non-PDF noise does not wake the indexer. Operational check: upload a test ordinance PDF, confirm the Event Grid subscription delivers a create event to the handler within expected latency, and verify the RAG index updates without any polling job running.