Один вопрос про Redis, который разделяет бэкендеров на два лагеря

«Расскажи, как ты используешь Redis.» Кандидат уверенно отвечает: кэширование, сессии, очереди. Интервьюер кивает. А потом задаёт один вопрос, после которого в комнате становится тихо: «Что произойдёт с твоим приложением, если Redis станет недоступен?»

Вопрос

Формулировки разные, суть одна:

— Redis упал. Что случится с твоим сервисом?

Иногда мягче: «Какие данные ты потеряешь, если Redis перезапустится?» Иногда жёстче: «У вас прод, пятница вечер, Redis OOM-killed. Твои действия?»

Почему этот вопрос задают

Потому что Redis — самая обманчивая технология в стеке. Она настолько проста в использовании, что разработчики перестают думать о последствиях. Поставил — работает. А потом Redis падает, и выясняется, что на нём держалось всё: от сессий до rate limiting, от кэша каталога до блокировок бизнес-логики.

По данным Habr, использовать Redis как основную базу данных для бизнес-критичных данных — почти всегда ошибка. Но использовать его как специализированный компонент для конкретных задач — отличное решение. Проблема в том, что большинство разработчиков не могут внятно объяснить, где у них проходит эта граница.

Два лагеря

Вопрос разделяет бэкендеров ровно на две группы.

Лагерь «это же просто кэш»: «Ну, Redis упал — запросы пойдут напрямую в базу. Немного медленнее, но работать будет.» Звучит разумно. Но интервьюер уже знает: этот человек не считал нагрузку.

Лагерь «мы в беде»: «Зависит от того, что мы туда положили. Если только кэш с TTL — переживём. Если сессии, очереди и распределённые блокировки — у нас проблема.» Этот ответ показывает: человек хотя бы раз видел, как Redis-зависимый сервис ложится.

Плохой ответ

«Redis — это кэш. Если упадёт, приложение просто будет ходить в базу данных. Станет медленнее, но ничего критичного.»

Что не так:

• Не учтён cache stampede. Если Redis обслуживал 10 000 запросов в секунду, и все они разом пошли в PostgreSQL — база ляжет за минуты. Это называется thundering herd, и это реальная проблема, которая кладёт проды
• Не учтены некэшевые данные. Сессии в Redis? Все пользователи разлогинятся. Очереди? Задачи потеряются. Rate limiting? Откроется шлюз для DDoS
• Нет плана. «Станет медленнее» — это не план. Это надежда

Хороший ответ

«Первое — нужно понять, что именно хранится в Redis. Кэш с TTL — это одно, stateful-данные — другое. Дальше зависит от архитектуры...»

И дальше — конкретика по трём уровням:

1. Graceful degradation для кэша. Если Redis — только кэш, приложение должно уметь работать без него. Но не «просто ходить в базу», а с защитой: circuit breaker на Redis-клиенте, fallback с local cache на пару минут, rate limiting на уровне приложения, чтобы не убить базу лавиной запросов.

2. Защита от cache stampede. Когда Redis возвращается после падения, кэш пустой. Тысячи запросов одновременно идут в базу за одними и теми же данными. Решения: request coalescing (single-flight) — только один запрос идёт в базу, остальные ждут результат. Или probabilistic early expiration — обновлять кэш до истечения TTL с нарастающей вероятностью, чтобы не было момента «всё протухло одновременно».

3. Чёткое разделение: что потеряем, а что нет. Сессии — дублировать в базу или использовать signed cookies. Очереди — если потеря недопустима, это не задача для Redis, а для RabbitMQ или Kafka с persistence. Распределённые блокировки через Redlock — иметь fallback-стратегию или хотя бы алерт.

Что на самом деле проверяют

Не знание команд Redis. SET, GET, EXPIRE знают все. Проверяют три вещи:

Понимание failure modes. Сеньор думает не «как это работает», а «как это ломается». Если ты не можешь описать, что случится при отказе компонента — ты не проектировал систему, ты копировал туториал.

Архитектурную гигиену. Где проходит граница между «потерять не страшно» и «потерять нельзя»? Если кандидат хранит в Redis и кэш каталога, и пользовательские транзакции — он не различает эти категории. Это красный флаг.

Опыт эксплуатации. Человек, у которого Redis падал в проде, расскажет про это конкретно: что легло, как восстанавливали, что поменяли после. Человек без такого опыта скажет «ну, станет медленнее».

Как подготовиться

Нарисуй свою Redis-карту. Возьми любой проект, с которым работал. Выпиши всё, что хранится в Redis. Для каждого элемента ответь: что произойдёт, если эти данные исчезнут? Если ответ «пользователи потеряют данные» — это проблема архитектуры, и тебе есть что рассказать.

Выучи три паттерна кэширования. Cache-aside, read-through, write-behind. Не определения — а когда какой применять и какие у каждого failure modes. По данным Medium, это одна из самых частых тем на собесах по system design.

Подготовь историю. «У нас Redis упал / переполнился / начал тормозить — и вот что произошло.» Если такой истории нет — смоделируй: «Если бы в моём текущем проекте Redis стал недоступен, первое, что сломается — это...»

Один вопрос про Redis показывает больше, чем час алгоритмов. Он раскрывает, думаешь ли ты о системе как о целом или только о своём куске кода.

Если хочешь потренировать system design вопросы в формате живого собеса — Sobes AI проведёт тебя через сценарий отказа, задаст уточняющие вопросы и покажет, где твой ответ теряет глубину. Не «выучи 50 вопросов», а «научись думать о системе так, чтобы любой вопрос был по плечу».