Если Redis — только ускоряющий кэш, допустим контролируемый fallback к БД после короткого timeout. Ошибку кэша нужно отличать от отсутствующего ключа и не превращать в бесконечные повторы.
Что будет, если cacheService упадёт или Redis вернёт таймаут, и как это обработать?
Если Redis — только ускоряющий кэш, допустим контролируемый fallback к БД после короткого timeout. Ошибку кэша нужно отличать от отсутствующего ключа и не превращать в бесконечные повторы.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Если Redis — только ускоряющий кэш, допустим контролируемый fallback к БД после короткого timeout. Ошибку кэша нужно отличать от отсутствующего ключа и не превращать в бесконечные повторы.
Используйте circuit breaker, ограничение параллельных fallback-запросов и метрики ошибок. Неудачная запись в необязательный кэш не должна отменять уже полученный корректный ответ БД, если это соответствует контракту. Но если Redis хранит обязательное состояние, например блокировку или единственную очередь, игнорировать отказ нельзя. Стратегия деградации зависит от роли хранилища и допустимой нагрузки на базу.