В распределенных системах бизнес-транзакции редко совпадают с классическими ACID-транзакциями, ну это #яснопонятно(👆про это постом выше 👆). Помним про один из ключевых способов, решающих эту задачу, — Saga; обсудив различные ее виды, включая разницу между оркестрацией и хореографией, мы так и не ответили на вопросы что делать, когда «все ложится звездой» и «как отследить выполнение бизнес-транзакции, размазанной по нескольким сервисам»? Сама концепция шаблона подразумевает использование множества атомарных шагов, каждый из которых выполняется(или нет) в отдельном сервисе. Тут все ок, но что делать если: 1️⃣ Шаг завершился с ошибкой, а компенсация не сработала. 2️⃣ Сообщение потерялось, из-за чего процесс завис в промежуточном состоянии. 3️⃣ Компенсация запустилась поздно или не запустилась вовсе.

🤷‍♂️🤯🤷‍♂️🤯🤷‍♂️🤯

Для начала стоит вообще поговорить, как бы нам упростить себе жизнь в «распределе», а затем ответить на вопросы выше?

1️⃣ Outbox Pattern Известная проблема Dual Write Problem решается довольно изящно и просто с помощью Outbox Pattern, т.е:

• Вместо прямой отправки события в брокер сообщений, сервис сначала записывает его в отдельную таблицу БД.
• Фоновый процесс читает из этой таблицы и отправляет сообщения в брокер.
• Гарантирует, что сообщение либо будет обработано, либо останется в БД для повторной попытки.

2️⃣ Retry & Backoff Strategy Некоторые ошибки (например, временная недоступность сервиса) можно исправить повторной попыткой, это так, но простые ретраи могут создать дополнительную нагрузку, поэтому стоит обратить внимание на:

• Exponential Backoff — инкриментально увеличивает паузу между попытками достучаться до внешней системы.
• Jitter — добавлять случайность в задержку, чтобы избежать лавинообразных нагрузок.
• Dead Letter Queue (DLQ) — отправлять сообщения в отдельную очередь, если они не обработаны после нескольких попыток, мол «последний привет из ада»

3️⃣ Idempotency Key Чтобы избежать повторного выполнения одного и того же шага в Saga из-за сбоев сети или дублирования сообщений, стоит использовать идемпотентные операции:

• Использовать идемпотентные ключи (например, уникальный TransactionID).
• Проверять, был ли уже обработан этот шаг.
• Перед обработчиком запросов извне применять шаблон Inbox.
• Не выполнять повторные действия, если они уже зафиксированы в БД. (ON CONFLICT DO NOTHING)

4️⃣ Distributed Tracing Jaeger, Zipkin, OpenTelemetry помогают визуализировать поток запросов между сервисами, что добавляет:

• Наглядность в последовательности шагов.
• Выявление узких места и задержки.
• Отслеживание, на каком шаге произошел сбой.

5️⃣ Monitoring & Alerting Тут подход очень простой - мы должны первыми знать, если в системе что-то идет не так, поэтому метрики - ваше все. Что будет полезным собирать?

• Количество успешных / неуспешных завершений Saga.
• Среднее время выполнения бизнес-транзакции.
• Количество запущенных компенсационных транзакций.
• Зависшие процессы, которые требуют ручного вмешательства.

Итак: ❗Шаг завершился с ошибкой, а компенсация не сработала: добавляем метрики, реализуем повторную доссылку компенсаций, на принимающей стороне компенсаций внедряем OUTBOX и/или DLQ ❗Сообщение потерялось, из-за чего процесс завис в промежуточном состоянии: добавляем метрики и мониторинг ❗Компенсация запустилась поздно или не запустилась вовсе: мониторим, DLQ в случае наступления дедлайна для реагирования #dev #arch #softwareengineering