Где хранится id сессии: в памяти сервера или иначе

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

Различаете ли вы идентификатор сессии и данные сессии и понимаете ли, что происходит с сессиями, когда инстансов приложения становится больше одного. Следом обычно спрашивают про sticky sessions, Spring Session и защиту от кражи сессии.

Как отвечать

Сначала разведите термины: идентификатор хранится у клиента, данные на сервере.

• идентификатор: случайная строка, которую сервлет-контейнер выдаёт при создании HttpSession и отправляет в куке JSESSIONID. Без кук возможна подстановка в URL (;jsessionid=), но её лучше запрещать: идентификатор утекает в логи и в заголовок Referer;
• данные: объект HttpSession с атрибутами. В Tomcat по умолчанию он лежит в памяти JVM у менеджера сессий, таймаут в Spring Boot задаётся server.servlet.session.timeout, по умолчанию 30 минут;
• несколько инстансов: сессию из памяти одного узла другой не видит. Варианты: sticky sessions на балансировщике (при падении узла его пользователи разлогинятся), репликация средствами контейнера (дорого на большом кластере) или внешнее хранилище;
• Spring Session: подменяет HttpSession реализацией поверх Redis, JDBC или Hazelcast, код приложения не меняется. Кука по умолчанию называется SESSION;
• без серверной сессии: JWT или другой самодостаточный токен. Сервер ничего не хранит, но отзыв токена до истечения срока требует отдельного механизма.

Закончите безопасностью: у куки флаги HttpOnly, Secure, SameSite, а после логина идентификатор меняется через HttpServletRequest.changeSessionId() против фиксации сессии. Spring Security делает это по умолчанию.

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

Отвечают «в памяти сервера» и не упоминают куку. Сервер хранит данные, а идентификатор приходит от клиента с каждым запросом.

Предлагают класть в куку сами данные сессии. Это лимит около 4 КБ на куку и риск подделки, если значение не подписано.

Не видят проблемы горизонтального масштабирования: после запуска второго инстанса пользователи внезапно разлогиниваются, а кандидат не может объяснить почему.