Паттерны бэкенда, часть 1: отказоустойчивость и консистентность

Эти паттерны спрашивают на собеседованиях на middle и senior, и отвечать определением из документации — худшее, что можно сделать. Спрашивают не «что такое circuit breaker», а «что у вас происходило, когда падал Redis»

Поэтому всё разобрано на одной системе — сервисе уведомлений. Он маленький, но в нём есть всё: входящие события, чужой API, кеш, база, очередь на отправку и воркеры по каналам. Каждая стрелка на схеме — место, где что-то отваливалось в проде

1. Circuit Breaker

Самое дорогое при отказе зависимости — не сам отказ, а ваше упорство. Сто запросов в секунду по 200 мс таймаута — это двадцать занятых соединений в каждый момент. Ещё немного, и сервис отвечает пятисотками на всё подряд, включая ручки, которым Redis вообще не нужен

Брейкер ставит между вами и зависимостью счётчик. Пока ошибок мало, он прозрачен. Как только их доля переваливает порог, он перестаёт пропускать вызовы вообще — и тем самым даёт упавшему сервису подняться

• Closed — трафик идёт как обычно, брейкер только считает ошибки в скользящем окне
• Open — порог пройден, вызовы отклоняются сразу, без похода в сеть
• Half-open — по таймеру пропускается один пробный вызов: ответ есть — закрываемся, нет — окно начинается заново

2. Graceful degradation

Источники у экрана разные по важности, но в коде это обычно ничем не выражено: всё лежит в одном Promise.all, и любой reject роняет всё. История уведомлений — смысл экрана. Аватарки рядом с ними — украшение. Для Promise.all это одно и то же

Деградация — это не «постараемся, чтобы не упало». Это заранее составленный список: вот ядро, вот это можно отдать заглушкой, вот это — старым значением с честной пометкой

• Разметьте зависимости на критичные и необязательные — до инцидента, а не во время
• У каждого необязательного вызова свой таймаут и своё «что вернуть, если не вышло»
• Старые данные помечаются старыми — задержку простят, молчаливое враньё нет
• Отказ ядра — это честный 503 с понятным текстом, а не белый экран

3. Retry с экспоненциальной паузой

Повтор лечит только временные сбои: сеть моргнула, провайдер перезагрузил ноду, база переключила мастера. Против ошибки в данных он бесполезен — сколько ни отправляй письмо на несуществующий адрес, оно не дойдёт

Опаснее другое. Внешний сервис прилёг — и повторы летят в него от всех ваших подов одновременно. Он поднимается, получает залп и падает снова. Так вы своими руками устраиваете ему DDoS в момент, когда он слабее всего

const BASE_MS = 1_000;
const CAP_MS = 30_000;
const JITTER = 0.2;

export function backoffDelay(attempt: number): number {
  const exponential = Math.min(BASE_MS * 2 ** attempt, CAP_MS);
  const spread = exponential * JITTER;
  return Math.round(exponential - spread + Math.random() * spread * 2);
}
// 1 → ~2.0 c, 2 → ~4.0 c, 3 → ~8.0 c, 6 → 30 c (потолок)

• Повторяем идемпотентное и только на 5xx, таймаут и обрыв соединения
• 400, 401, 422 не повторяем — тело запроса не изменится, а нагрузку вы создадите
• Джиттер обязателен — без него весь кластер просыпается в одну миллисекунду
• У повторов есть потолок паузы и предел попыток, дальше — DLQ

4. Rate limiting

Лимит — это не защита от злоумышленников, а защита от любой неравномерности. Забытый setInterval в чужом коде, ретрай без бэкоффа, выгрузка отчёта в цикле — все они выглядят как атака и лечатся одинаково

Классический алгоритм — token bucket: ведро с токенами, которое наполняется с постоянной скоростью. Короткий всплеск проходит за счёт накопленного, длинный поток упирается в скорость наполнения. Это честнее фиксированного окна, где на границе двух окон можно пропихнуть двойную норму

• Считаем по владельцу — userId или ключ API, а не по IP
• Отвечаем 429 и Retry-After — клиент должен понимать, когда возвращаться
• Лимит хранится в Redis, иначе у каждой реплики будет свой, и общий окажется втрое больше
• Отказ должен быть дешёвым — проверка идёт до похода в базу, иначе лимит сам станет нагрузкой
• Разные ручки — разные лимиты: выгрузка отчёта и чтение ленты не могут стоить одинаково

5. Работа с внешним API

Единственное, чем вы управляете в интеграции, — как именно вы туда ходите. Три предыдущих паттерна работают здесь вместе, и порядок имеет значение: таймаут ограничивает одну попытку, повтор даёт второй шанс, брейкер прекращает попытки целиком, когда стало ясно, что шанса нет

1. Таймаут на соединение и отдельно на чтение — по умолчанию HTTP-клиенты ждут вечно
2. Повтор с паузой и джиттером, только для безопасных операций
3. Брейкер по каждому провайдеру отдельно, а не один на все интеграции
4. Свой пул соединений на провайдера, чтобы медленный не съел воркеры остальных
5. Метрики в разрезе провайдера: p99, доля ошибок, состояние брейкера

6. Event-Driven Messaging

Синхронный вызов связывает два сервиса жёстче, чем кажется: он тащит за собой и знание об адресате, и его аптайм, и его скорость. Событие переворачивает зависимость — теперь потребитель знает про продюсера, а не наоборот

Событие описывает то, что уже случилось, в прошедшем времени: user.registered, а не send_welcome_email. Разница не косметическая — команда подразумевает конкретного исполнителя, факт не подразумевает никого

• У каждого потребителя своя consumer-группа, свой оффсет и своя скорость
• Потребитель лёг — события копятся в топике, а не теряются в воздухе
• Новый потребитель подключается без единой правки у продюсера
• Порядок гарантирован только внутри партиции — ключ партиционирования выбирается осознанно

7. Transactional Outbox

Код выглядит невинно: сохранили уведомление, отправили событие. Но между COMMIT и publish нет ничего, что связывало бы их вместе — это два разных хранилища с двумя разными механизмами отката

Дальше сценарий на выбор. Процесс умер после коммита — данные есть, события нет, письмо не уйдёт никогда. Событие ушло, а транзакция откатилась — письмо про платёж, которого не было. Оба случая всплывают редко и разбираются мучительно

await db.transaction().execute(async trx => {
  await trx.insertInto('notifications').values(notification).execute();

  await trx
    .insertInto('outbox')
    .values({
      aggregate_id: notification.id,
      topic: 'notification.created',
      payload: JSON.stringify(payload),
    })
    .execute();
});
// Kafka здесь нет. Публикует отдельный процесс — из того, что уже закоммичено

• Данные и строка outbox пишутся одним COMMIT — атомарность обеспечивает база
• Publisher читает неотправленные строки с FOR UPDATE SKIP LOCKED, поэтому его можно масштабировать
• После публикации строка помечается отправленной
• Падение между publish и отметкой даёт повтор — это at-least-once по определению, и потребитель обязан быть к нему готов

8. Transactional Inbox

Outbox гарантирует, что событие уйдёт хотя бы раз. Ключевое слово — «хотя бы». Ребаланс группы, повтор publisher, переподключение консьюмера: одно и то же сообщение приезжает второй раз, и это штатная работа брокера, а не сбой

Inbox — зеркальная половина outbox. Не «на всякий случай», а обязательное условие: при at-least-once дубли гарантированы, вопрос только в том, заметите вы их или пользователь

await db.transaction().execute(async trx => {
  const inserted = await trx
    .insertInto('inbox_messages')
    .values({ message_id: message.id, consumer: 'notification' })
    .onConflict(oc => oc.columns(['message_id', 'consumer']).doNothing())
    .executeTakeFirst();

  // Строка уже была — событие обработано раньше, второй раз не отправляем
  if (Number(inserted.numInsertedOrUpdatedRows ?? 0) === 0) return;

  await sendPush(trx, message.payload);
});

• Уникальный индекс по (message_id, consumer) — дедупликация лежит на базе, а не на коде
• Проверка и сам эффект живут в одной транзакции, иначе между ними снова появляется щель
• Оффсет коммитится и для дубликата — он обработан корректно, то есть осознанно пропущен
• Записи чистятся по расписанию, иначе таблица растёт вечно

9. Идемпотентность и Idempotency-Key

Три предыдущих паттерна опираются на это слово: retry повторяет, outbox доставляет минимум один раз, inbox отбивает дубли на стороне потребителя. Но у публичного API нет ни inbox, ни оффсетов — там повтор приходит от живого клиента, и защищаться надо иначе

Идемпотентность — это свойство операции: повторный вызов не меняет результат. GET и DELETE идемпотентны сами по себе, PUT обычно тоже. POST — нет, и именно ему нужен ключ

const existing = await keys.find(idempotencyKey, userId);

if (existing) {
  // Тот же ключ с другим телом — это ошибка клиента, а не повтор
  if (existing.requestHash !== hashOf(body)) throw new ConflictException();
  return existing.response;
}

return db.transaction().execute(async trx => {
  const payment = await charge(trx, body);
  const response = { id: payment.id, status: payment.status };

  await trx
    .insertInto('idempotency_keys')
    .values({ key: idempotencyKey, user_id: userId, request_hash: hashOf(body), response })
    .execute();

  return response;
});

• Ключ генерирует клиент — это идентификатор попытки, а не платежа
• Хранится сам ответ, а не только факт «ключ был»: повтору надо что-то вернуть
• Хеш запроса ловит тот же ключ с другим телом и отдаёт 409
• Ключ скоуплен на владельца, иначе чужой запрос с угаданным ключом получит ваш ответ
• У ключа есть TTL — суток хватает на любые сетевые повторы

10. Dead Letter Queue

Такое сообщение называют ядовитым: пришло без обязательного поля, схема разъехалась, данные битые. Повторы его не вылечат — оно не станет валидным от того, что вы попробуете ещё раз

Поэтому бесконечный ретрай здесь — это не устойчивость, а вечная остановка партиции. Лечится одним способом: убрать сообщение с дороги, но не потерять

• N попыток с бэкоффом, потом перенос в topic.DLT
• Вместе с телом переносятся причина, стектрейс, исходный топик, партиция и оффсет
• Счётчик сообщений в DLT — обязательная метрика, а не приятное дополнение
• Алерт на первое же сообщение — в норме очередь пуста
• После починки сообщения переигрываются обратно в основной топик

11. Pub/Sub в Redis

Соединения раскиданы по подам как попало — пользователь подключился туда, куда его завёл балансировщик. Знать эту раскладку невозможно и не нужно: вместо адресации получателя мы делаем рассылку, а лишние инстансы просто молча игнорируют

• PUBLISH доставляется только тем, кто подписан прямо сейчас
• Подписчик был отключён — сообщение для него не существовало, повтора не будет
• Ни очереди, ни оффсетов, ни подтверждений — доставка не гарантирована в принципе
• Зато задержка в миллисекундах и никакой отдельной инфраструктуры

12. Saga и виды саг

Двухфазный коммит существует, но в микросервисах от него отказались: он блокирует ресурсы на всё время согласования и умирает вместе с координатором. Сага честно признаёт другое — атомарности не будет, будет последовательность шагов, каждый из которых коммитится сам по себе

Компенсация — это не rollback. Откатывать уже нечего: чужой сервис давно закоммитил своё. Это новое бизнес-действие, обратное по смыслу — возврат вместо отмены списания

Оркестрация

Отдельный компонент знает весь сценарий, вызывает шаги по очереди и хранит состояние саги. Плюс — сценарий целиком читается в одном файле, и по состоянию видно, где именно всё встало. Минус — оркестратор становится центром, от которого зависят все, и его отказ останавливает процесс

Хореография

Центра нет: каждый сервис слушает событие предыдущего и публикует своё. Плюс — связность ниже, добавить шаг проще. Минус — сценарий целиком не написан нигде, и как только шагов становится больше трёх, вопрос «почему подписка активна, а денег не списали» превращается в раскопки по логам всех участников

Что дальше

Двенадцать паттернов выше отвечают на один вопрос: как система переживает отказы и не теряет данные. Это половина разговора на собеседовании

Вторая половина — про то, как всё это живёт в кластере: как сервисы находят друг друга, как выкатываются без потерь, как за ними смотреть и как менять контракты, ничего не сломав