Когда говорят о stateless-приложении, имеют в виду компонент, который не помнит, что было в прошлый раз. Каждый запрос для него как новый: никакой информации о пользовательской сессии, шагах до этого, промежуточных результатах — ничего не хранится внутри самого сервиса между вызовами.
Из-за этого такая архитектура отлично масштабируется по горизонтали. Хочется больше производительности — просто поднимаем дополнительно несколько инстансов, и всё, им не нужно друг с другом синхронизировать какое-то внутреннее состояние. Один экземпляр упал — запросы спокойно уезжают на другие, пользователи этого даже не замечают, если всё сделано правильно.
Типичные примеры stateless-сервисов:
– REST API, которые не держат сессии и работают чисто по запрос–ответ,
– микросервисы, которые приняли задачу, что-то посчитали и сразу вернули результат,
– контейнерные приложения в Kubernetes, у которых при перезапуске вообще нет идеи «сохранять состояние» внутри пода.
Для контраста:
- Stateless — легко масштабируется, быстро оживает после сбоев, хорошо ложится на облака и CI/CD-процессы.
- Stateful — уже привязано к данным: пользователи, сессии, транзакции и прочее. Это всякие базы данных, брокеры очередей, кэши и тому подобное.
В современных DevOps-средах ставка обычно как раз на stateless-компоненты: их проще автоматизировать, переносить между окружениями и держать отказоустойчивыми. Всё, что «долго живёт», стараются выносить в отдельные хранилища или специализированные сервисы.
