Почему переход со stateful на stateless-архитектуру сложен на поздних этапах?

Stateful-архитектура означает, что сервер помнит состояние клиента между запросами: сессию в памяти, открытые соединения, кэш, промежуточные вычисления. Stateless-подход требует, чтобы каждый запрос был самодостаточным, а состояние хранилось во внешних системах (Redis, БД, JWT). На ранних этапах переход дешёв, потому что кода мало и связей почти нет.

Почему на поздних этапах это дорого

• Состояние «размазано» по singleton-объектам, статическим полям, локальным кэшам и in-memory-сессиям.
• Клиенты и другие сервисы уже полагаются на текущее поведение: sticky sessions, порядок запросов, сохранённые идентификаторы.
• Тесты, мониторинг и деплой завязаны на конкретные инстансы и их память.
• Горизонтальное масштабирование требует репликации состояния или sticky-балансировки, что усложняет инфраструктуру.

Пример: сессия в памяти

// Stateful: сессия живёт в памяти процесса
const sessions = new Map();
app.post('/login', (req, res) => {
  const id = crypto.randomUUID();
  sessions.set(id, { user: req.body.user });
  res.cookie('sid', id);
});

// Stateless: состояние в Redis или JWT
app.post('/login', async (req, res) => {
  const token = jwt.sign({ user: req.body.user }, SECRET);
  res.cookie('token', token);
});

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

Что делать при миграции

1. Вынести сессии и кэш во внешнее хранилище (Redis, Memcached).
2. Заменить in-memory-состояние на токены или идентификаторы, передаваемые в запросе.
3. Ввести версионирование API, чтобы старые клиенты работали параллельно.
4. Постепенно переводить сервисы, начиная с наименее связанных.

Stateless-архитектура упрощает масштабирование, отказоустойчивость и деплой, но требует дисциплины: состояние всегда должно быть явным и внешним. Применять переход стоит, когда сервис начинает масштабироваться горизонтально или когда появляются требования к zero-downtime-деплою.