Транзакційний меседжинг

Транзакційний меседжинг - це набір архітектурних прийомів, які забезпечують узгодженість між локальними змінами стану (БД/кеш) і повідомленнями в брокері/шині. Мета: «стан зафіксовано ↔ повідомлення не втрачено і не продубльовано» при збоях, ретраях, масштабуванні і мульти-тенантності.

1) Семантика доставки

At-most-once: швидко і дешево, можливі втрати, дублів немає.
At-least-once: не втрачає повідомлення, можливі дублі → потрібна ідемпотентність.
(Ефективне) Exactly-once: немає втрат і немає видимих дублів для бізнес-ефектів, досягається комбінацією технік (outbox/inbox, транзакції продьюсера/консьюмера, дедуп).

2) Чому «двописьмо» небезпечно

Наївна логіка «спочатку запишемо в БД, потім відправимо в шину» (або навпаки) рветься при падінні між кроками: дані зафіксовані, а подія втрачена; або подія пішла, а даних немає. Транзакційний меседжинг усуває цей розрив.

3) Базові патерни

3. 1 Outbox (виробник)

В одній локальній транзакції записуємо бізнес-зміна і рядок в таблицю'outbox'; окремий паблішер читає outbox і публікує в брокер з ретраями і backoff. Втрати виключені; дублі гасимо ідемпотентністю у споживачів.

3. 2 Inbox/Idempotent Consumer (споживач)

Перед виконанням ефекту консьюмер робить'INSERT'в'inbox (consumer, event_id)'як первинний ключ. Конфлікт ключа = подія вже оброблена → пропускаємо. Так досягається «ефективне exactly-once».

3. 3 Read-Process-Write з транзакцією офсету

Шаблон для лог-орієнтованих шин: консьюмер читає батч, в тій же транзакції фіксує бізнес-зміна і «пройдений офсет». Після коміту брокер вважає повідомлення спожитими. Це усуває «прочитали → впали → повторили» без дублів в ефекті.

3. 4 ТСС/Саги для міжсервісних ефектів

Коли потрібен узгоджений мультишаговий процес, використовуємо TCC або саги; сполучення - транспорт команд/подій, а транзакційність - на рівні кроків і компенсацій.

4) Ідемпотентні продьюсери та консьюмери

Продьюсер: стабільний'message _ id '/' idempotency _ key', повторна відправка з тим же ключем не створює нових ефектів у передплатників; підтримуйте послідовність (sequence) за ключем.
Консьюмер: «inbox» + бізнес-ідемпотентність (upsert/merge, перевірка останньої версії/ревізії).

5) Порядок і причинність

Партиціонуйте по бізнес-ключу (наприклад,'aggregate _ id','tenant _ id'), щоб події одного об'єкта приходили в порядку.
Всередині партії зберігайте послідовні номери/часові мітки; при редрайві з DLQ дотримуйтесь «по ключу і послідовно».
Якщо глобальний порядок не критичний, забезпечуйте локальний порядок за ключем і фіксуйте інваріанти домену.

6) Офсети і фіксація ефектів

Варіант A: «Офсет в БД»

Записуйте «останній оброблений офсет (partition, offset)» в ту ж транзакцію, де змінюєте доменні дані. При рестарті продовжіть з наступного офсету, уникаючи повторного ефекту.

Варіант B: «Транзакція брокера»

Деякі брокери підтримують атомарний запис повідомлень і офсетів в рамках однієї транзакції продьюсера/консьюмера. Використовуйте, якщо доступно, але завжди доповнюйте ідемпотентністю на споживачі.

7) Ретраї, backoff, DLQ

Повторюйте тільки ретраібл-помилки (таймаути, 5xx), з експоненціальним backoff і джиттером.
Нон-ретраібл (schema/валідація) - відразу в DLQ з метаданими (tenant, key, offset, причина).
Редрайв з DLQ дозуйте (batch, rate limit), перевіряйте схему перед повтором, дотримуйтесь порядку за ключем.

8) Мульти-тенантність і регіони

Включайте'tenant _ id','plan','region'в метадані повідомлення і ключі партіонування.
Per-tenant fairness: лімітуйте публікацію/обробку, щоб «галасливий» клієнт не виїв бюджет у інших.
Residency: зберігайте повідомлення і outbox в тому ж регіоні, що і доменні дані; міжрегіональні реплікації - асинхронні агрегати.

9) Спостережуваність і аудит

Трейсинг: кореляція'event _ id '/' aggregate _ id '/' saga _ id', спани «read → process → write/commit».
Метрики: лаг публікації/обробки (p95/p99), частка успіхів, DLQ-rate, успіх редрайва, «дублікати пригнічені».
Логи: коротко на успіх; детально на помилки (причина, спроба, ключ, офсет).
Аудит: хто редрайвіл/відкочував, яким батчем і з яким результатом.

10) Безпека та відповідність

Мінімізуйте PII в payload; маскуйте при перенесенні в DLQ/логи.
Підписуйте/шифруйте повідомлення для зовнішніх шин; використовуйте mTLS між сервісами.
Керуйте терміном зберігання і «правом на забуття» per tenant/region.

11) Типові схеми інтеграції

1. Сервіс-джерело (write-side)

Локальна транзакція: доменний запис + outbox.
Паблішер: батчі,'SKIP LOCKED', backoff, ліміти per tenant.
Моніторинг лага'now − occurred_at'.

2. Сервіс-споживач (read-side)

Читання батча → спроба'INSERT inbox (consumer, event_id)'→ при успіху виконуємо ефект.
У тій же транзакції фіксуємо «пройдений офсет» (варіант A) або покладаємося на транзакцію брокера (варіант B).
На помилці: ретрай або DLQ з політики.

3. Проекція/матеріалізований вигляд

Тільки ідемпотентні апдейти (upsert), компактні ключі дедупа, періодична звірка контрольних сум.

12) Конфігураційні шаблони (приклад)

yaml producer:
idempotency_key: event_id partition_key: "{tenant_id}:{aggregate_id}"
retry:
max_attempts: 8 initial_ms: 200 max_ms: 8000 strategy: exponential_full_jitter

consumer:
batch: 500 offset_commit: "with_domain_tx"  # или "broker_tx"
inbox_enabled: true concurrency_per_partition: 4 dlq:
enabled: true batch_redrive: 200 rate_limit_per_sec: 50 order_by_key: true

observability:
metrics:
- processing_lag_ms
- publish_success_ratio
- dlq_rate
- redrive_success_ratio tracing_tags: [event_id, tenant_id, aggregate_id, partition, offset]

13) Чек-лист перед продом

• Усунуто «двописьмо»: outbox на продьюсері або фіксація офсету і ефекту в одній транзакції у консьюмера.
• Ідемпотентний консьюмер: «inbox »/дедуп-журнал, бізнес-ідемпотентність операцій.
• Партіонування по бізнес-ключу, локальний порядок дотриманий.
• Ретраї з backoff + джиттером, класифікація помилок, DLQ з багатими метаданими.
• Редрайв дозований, безпечний; є плейбуки.
• Мульти-тенантні ліміти та пріоритети; теги'tenant _ id/plan/region'.
• Телеметрія: лаги, частка успіхів, «дублікати пригнічені», алерти по p95/p99.
• Політики PII/ретеншну/шифрування дотримані.
• Тести: падіння між кроками, дублікати, порядок за ключем, масовий редрайв.

14) Типові помилки

Відправка в шину і запис в БД роздільними кроками без outbox/транзакції офсета.
Консьюмер без ідемпотентності → дублює побічні ефекти.
Глобальний порядок «будь-що» - доріг і рідко виправданий; достатньо порядку за ключем.
Масовий редрайв без лімітів → вторинний інцидент.
Відсутність трейсингу/лаг-метрик → «прихована деградація».
Змішування PII в DLQ/логах.

15) Швидкі рецепти

SaaS-події: Outbox + ідемпотентний консьюмер (inbox), партіонування по'tenant _ id:aggregate_id`.
ETL/проекції: Read-process-write з фіксацією офсетів в одній транзакції, батчі 500-1000, upsert.
Високе навантаження: шардування паблішерів,'SKIP LOCKED', WFQ per tenant, контроль лага.
Сувора комплаєнс-зона: регіональні outbox, шифрування payload, ретеншн і аудит редрайвів.

Висновок

Транзакційний меседжинг - це дисципліна з'єднання даних і повідомлень. Комбінуючи outbox/inbox, ідемпотентність, фіксацію офсетів разом з ефектами і керовані ретраї з DLQ, ви отримуєте практичну exactly-once-поведінку без глобальних блокувань і зберігаєте SLO навіть при збоях, піках і складній мульти Тенантна експлуатація.