Какие плюсы и минусы использования Redis и куки для хранения данных

Что проверяют

Понимаете ли вы, что Redis и куки не конкуренты на одном уровне, а два места для состояния: на сервере и у клиента. Интервьюер хочет услышать, где хранить сессию в Spring-приложении с несколькими инстансами. Следом обычно спрашивают, как отозвать сессию и что будет, если Redis упал.

Как отвечать

Сформулируйте выбор честно: либо в куке лежит только идентификатор, а данные сессии живут в Redis, либо всё состояние едет в самой куке, подписанное или зашифрованное (сюда же JWT в куке).

Redis как хранилище сессий:

• плюсы: данные не уходят клиенту, объём не ограничен размером заголовка, сессию можно удалить мгновенно (выход со всех устройств, блокировка). В Spring Boot хватает зависимости spring-session-data-redis, автоконфигурация подключит её сама, клиент по умолчанию Lettuce;
• минусы: лишний сетевой поход на каждый запрос и ещё одна точка отказа. Память конечна: при достижении maxmemory поведение задаёт maxmemory-policy, и политика по умолчанию noeviction отказывает в записи. Нужны TTL, пароль или ACL, закрытый порт.

Куки как хранилище:

• плюсы: сервер остаётся без состояния, инстансы масштабируются проще, нет внешней зависимости;
• минусы: около 4 КБ на куку, все куки домена едут в каждом запросе, а у Tomcat лимит заголовков по умолчанию 8 КБ. Отозвать подписанную куку до истечения срока нельзя без чёрного списка, то есть без того же хранилища. Без подписи клиент меняет данные как хочет.

Атрибуты назовите сразу: HttpOnly против чтения скриптом, Secure, SameSite=Lax или Strict против CSRF. В Spring куку удобно собирать через ResponseCookie.

Где спотыкаются

Кладут в куку роль пользователя или сумму корзины без подписи. Это прямое приглашение подменить значение в DevTools.

Считают Redis надёжной базой. Даже с RDB-снимками теряется всё, что записано после последнего снимка, а без реплики падение узла кладёт авторизацию целиком.

Говорят, что HttpOnly защищает от XSS. Он лишь не даёт скрипту прочитать куку, а запросы от имени пользователя вредоносный скрипт всё равно отправит.