Stateful-приложение устроено ровно наоборот: оно помнит, что с ним происходило между запросами. У него есть состояние — кто пользователь, на каком шаге он остановился, какие данные уже записаны, какие операции идут в процессе и так далее. Это всё не пропадает между обращениями и учитывается дальше.
Без постоянного хранилища такие штуки просто не живут. Если взять Kubernetes, то для подобных приложений почти всегда подключают Persistent Volume, чтобы при перезапуске пода или переносе его на другой узел данные не исчезали. Поды могут мигрировать, а вот состояние — нет, оно должно оставаться доступным.
Типичные примеры stateful-систем:
– базы данных: PostgreSQL, MongoDB и прочие,
– системы очередей: RabbitMQ, Kafka,
– крупные бизнес-приложения: CRM, ERP, финансовые и логистические платформы, где потеря истории операций недопустима по определению.
С такой архитектурой уже не получится просто «накидать инстансов». Нужно отдельно думать про масштабирование, резервные копии, обновления, репликацию, что будет при сбое узла. Потеряли состояние — поломали бизнес-процессы. Поэтому stateful-приложения разворачивают аккуратно: с отказоустойчивыми схемами и понятной стратегией хранения данных.
Разделение сервисов на stateful и stateless сильно помогает при проектировании облачных решений. Понимаешь, где у тебя просто расчётный слой (API, микросервисы), а где критичные к данным компоненты, и под это уже выбираешь инфраструктуру, подход к развёртыванию и уровень защищённости.
