Chatty RAG clients threaten the shared Cosmos DB RU budget during council-meeting nights. What client-side protection fits?
Select an answer to reveal the explanation.
Short Explanation
Rate limits are the velvet rope outside the council-night RAG club—chatty clients wait their turn so the shared Cosmos RU budget doesn’t get stampeded.
Full Explanation
Chatty RAG clients that threaten the shared Cosmos DB RU budget during council-meeting nights need client-side rate limiting aligned to capacity so bursty municipal traffic cannot starve the shared store used by multiple departments and resident-facing bots. Removing all client throttling and allowing unlimited concurrent RAG calls into Cosmos invites account-wide 429s during peak civic events when meeting packets and FAQs surge together. Disabling Cosmos entirely on council nights and serving random answers abandons grounded retrieval when residents and staff most need accurate meeting-related answers. Raising every client’s concurrency without observing RU or 429 signals amplifies load instead of protecting the shared budget and worsens throttling cascades across the city platform. Exam caveat: rate limits complement retry-with-backoff and semantic cache layers; they do not replace correct RU provisioning or partition design for hot meeting containers. Operationally, enforce per-client and global RAG QPS limits, watch 429 rates and normalized RU on council nights, load-test with synthetic chatty clients before the next peak event, and document backoff behavior for FAQ bots and indexer callers.