🚨 Роняем базу из-за кеша без смс и регистрации

Горячий ключ кэша истёк — и за 2 секунды база получила 10 000 одновременных запросов. Попадания в кеш были ~ 95%, пятничных релизов не было, плохих запросов в БД никто не отправлял. Просто одновременно закончился TTL на тысячах инстансов. Они одномоментно не нашли данных в кеше и полезли за ними в БД

Что помогает, если ключи реально «горячие» (то есть, какие-то пары ключ/значение в кеше запрашиваются крайне часто).

– Stale-while-revalidate: если запись просрочена, но есть, то отдаём её сразу, а обновление запускаем параллельно.

– Probabilistic early expiration: часть запросов с небольшой вероятностью инициирует обновление до дедлайна, чтобы обновления распределились по времени.

– Mutex / single-flight: при промахе один запрос обновляет кэш под блокировкой, остальные ждут немного или получают stale; в базу уходит один запрос вместо тысячи.

Комбинация этих подходов в реальных системах снижает нагрузку на БД во время истечения срока на 50–90% и сглаживает пики задержек.

📚 Полный текст по ссылке: https://habr.com/ru/companies/spring_aio/articles/993140/