Many 311 API pods miss Azure Managed Redis simultaneously during an outage recovery. What problem should the team prevent?
Select an answer to reveal the explanation.
Short Explanation
A cache stampede is a hundred clerks stampeding the copy machine after the outage—locks or single-flight say ‘one rebuild, everyone else waits’ so Redis and the LLM don’t melt.
Full Explanation
When many 311 API pods miss Azure Managed Redis simultaneously during outage recovery, uncoordinated cache misses can stampede origin systems and the LLM path. Protecting against a cache stampede with locks or single-flight regeneration ensures only one worker rebuilds a given FAQ answer while others wait or reuse the result, preserving municipal cost and latency budgets. Allowing every pod to regenerate the identical FAQ answer concurrently with no coordination multiplies identical embedding and generation work and can overwhelm downstream Azure AI and data services. Deleting Redis entirely and regenerating from the LLM on every keystroke forever removes caching as a stabilizing layer and maximizes token and RU spend. Pinning all cache keys with infinite TTL and never refreshing after model or content changes avoids stampede but serves stale civic answers after ordinance or model updates. Exam caveat: stampede control is about coordinated regeneration under synchronized misses, distinct from ordinary TTL and eviction tuning. Operationally, implement single-flight or lock-around-miss for hot FAQ keys, load-test simultaneous cold starts across pods, and verify origin QPS stays bounded during Redis failover drills.