Кэш обычно ставят с простой целью: не ходить в базу на каждый запрос и снять с неё часть нагрузки.
Проблемы начинаются, когда много востребованных ключей записывают почти одновременно и задают им одинаковый TTL. После их истечения приложение получает волну cache miss и отправляет запросы в PostgreSQL.
Дальше цепочка довольно неприятная. То, что раньше спокойно закрывалось из Redis, внезапно идёт в базу. PostgreSQL получает резкий скачок нагрузки, растёт время выполнения запросов и ожидание свободных соединений. А потом деградация уже может пойти дальше – в сервисы, которые от этой базы зависят.
То есть Redis сам по себе не «роняет» PostgreSQL. Проблема возникает в момент, когда кэш перестаёт брать на себя привычную долю трафика, а база внезапно остаётся один на один со всем потоком.
✔️Самое очевидное, что здесь можно сделать, – не записывать большому числу горячих ключей одинаковый TTL. Небольшой случайный разброс уже снижает риск того, что они истекут одной волной.
Если много запросов одновременно пытаются загрузить один и тот же отсутствующий ключ, помогает singleflight. Он объединяет одновременные загрузки одного ключа внутри экземпляра сервиса: один запрос выполняется, остальные используют его результат.
Дальше уже идут soft/hard TTL и background refresh. То есть в некоторых сценариях лучше какое-то время отдавать не самое свежее значение, пока новое обновляется в фоне, чем дождаться полного истечения TTL и отправить весь трафик в источник.
И отдельно нужно продумать, что делать, если сам Redis недоступен.
При отказе Redis нужно ограничивать частоту и число одновременных обращений к PostgreSQL. Если база не выдерживает весь входящий трафик, безопаснее временно ограничить часть запросов или функциональность, чем перегрузить общий источник данных. Такой режим лучше заранее проверить нагрузочным тестом с отключённым кэшем.
На курсе «Паттерны отказоустойчивости в микросервисах на Go» кэш разбираем именно с этой стороны: stale data, thundering herd, cache avalanche, topology, eviction и поведение системы при падении Redis.
🗓Курс стартует 27 октября и длится 1,5 месяца. За это время пройдём путь от базовой диагностики отказов до retry, circuit breaker, Kafka, кэшей, observability и полноценного GameDay с инцидентом, rollback и postmortem. Все темы – на одном смоделированном TravelTech-проекте, с практикой и разбором реальных сценариев отказов.