Нельзя просто направить весь поток после отказа кэша в БД. Нужны лимит fallback-запросов, объединение одинаковых промахов, короткие timeout и управляемая деградация.
Если кеш таймаутит и запросы начинают массово уходить в БД, как снизить нагрузку на базу?
Нельзя просто направить весь поток после отказа кэша в БД. Нужны лимит fallback-запросов, объединение одинаковых промахов, короткие timeout и управляемая деградация.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Нельзя просто направить весь поток после отказа кэша в БД. Нужны лимит fallback-запросов, объединение одинаковых промахов, короткие timeout и управляемая деградация.
Circuit breaker прекращает бесполезное ожидание Redis, но сам не защищает базу от возросшего потока. Ограничьте параллелизм к БД и очереди, отдавайте допустимые устаревшие данные либо явную ошибку при исчерпании бюджета. Запретите лавину повторов, добавьте jitter при восстановлении и контролируйте hit rate, latency и активные запросы. Критичные данные нельзя произвольно заменять устаревшими — это определяется бизнес-контрактом.