Stateless backend не хранит критическое состояние пользователя только в памяти одного экземпляра. Поэтому следующий запрос может обработать другая реплика, а добавление или замена сервера не теряет сессию.
Почему бэкенд должен быть stateless для горизонтального масштабирования?
Stateless backend не хранит критическое состояние пользователя только в памяти одного экземпляра. Поэтому следующий запрос может обработать другая реплика, а добавление или замена сервера не теряет сессию.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Stateless backend не хранит критическое состояние пользователя только в памяти одного экземпляра. Поэтому следующий запрос может обработать другая реплика, а добавление или замена сервера не теряет сессию.
Состояние при этом никуда не исчезает: его размещают в БД, общем кеше или другом согласованном хранилище. Локальные кеши допустимы, если их потеря безопасна. Stateful-сервисы тоже масштабируют, но им нужны распределение владения, репликация и восстановление. Sticky sessions могут упростить маршрутизацию, однако не решают потерю состояния при отказе выбранной реплики.