Message Broker і маршрутизація подій

(Розділ: Технології та Інфраструктура)

Коротке резюме

Message Broker - фундаментальний шар інтеграцій і подієвої шини в iGaming. Він реалізує доставку, буферизацію і маршрутизацію повідомлень між мікросервісами ставок, платежів, антифроду, KYC, CRM і аналітики. Грамотно спроектовані обмінники (exchanges), черги, ключі маршрутизації і правила повторної доставки забезпечують низьку затримку, стійкість до сплесків трафіку і передбачувані SLO.

Роль брокера в платформі iGaming

Декуплінг сервісів: публікація подій замість жорстких синхронних викликів.
Гнучка маршрутизація: один івент → багато споживачів (CRM, ризик, аналітика).
Управління навантаженням: черги, prefetch/QoS, бекпрешер.
Надійність і відновлення: підтвердження, ретраї, DLQ, реплікація.
Аудит та комплаєнс: трасування подій, маскування PII, політика зберігання.

Моделі обміну повідомленнями

Point-to-Point (черга завдань): один споживач обробляє завдання (KYC, e-mail, PSP webhook).
Pub/Sub (події домену): публікація в обмінник з фан-аутом на кілька черг.
RPC через брокер: запит/відповідь з кореляцією (рідко на «гарячих» шляхах, але корисно для інтеграцій).

Концепції маршрутизації (AMQP-класика)

1. direct - точний збіг'routing _ key'.

2. topic - шаблони'a. b. c'с "(одне слово) і'#'( 0 + слів). Універсальний вибір.

3. fanout - широкомовно всім пов'язаним чергам.

4. headers - маршрутизація по заголовках (ключ/значення), корисно для складних політик.

• `payments. psp. stripe. succeeded`, `payments. psp..failed`, `bets. live. #`, `rg. limit. breach`.
• Обмінники по доменах: `payments. topic`, `bets. topic`, `risk. topic`; окремі - для системних подій'platform. audit`.

Черги та політики

Робоча черга: споживається бізнес-хендлерами.
Retry-черги: з TTL (delay) і DLX для експоненціальних бекофів (наприклад,'5s → 1m → 5m → 1h').
DLQ (Dead-Letter Queue): остаточне «звалище» після вичерпання ретраїв.
Priorities: для термінових завдань (висновки> листи).
Lazy/Quorum: lazy - економія RAM при великих беклогах; quorum - HA на базі консенсусу.

• `work. q` → `x-dead-letter-exchange=retry. ex`
• `retry. 1m. q` → `x-message-ttl=60000`, `x-dead-letter-exchange=work. ex`
• `dlq. q'→ моніторинг і ручна ремедіація

Гарантії доставки та порядок

At-least-once - дефолт: можливі дублікати → ідемпотентність обов'язкова.
At-most-once - мінімальна затримка, але ризик втрат (для «не критичних» сигналів).
Exactly-once - рідко практично в брокерах; досягається складніше і дорожче. Для грошей: at-least-once + жорстка ідемпотентність.

• В одній черзі і при одиночному споживачі порядок зберігається; при паралелізмі + ретраях порядок може порушуватися.
• Для сутностей з вимогою порядку - серіалізуйте потік (single-active consumer на ключ) або перенесіть в «лігві» шини (стрімінг).

Ідемпотентність і транзакційна публікація

Idempotency-Key в повідомленні (ULID/UUID), дедуп-сховище з TTL або upsert по ключу.
Outbox-патерн: запис події в таблицю'outbox'в рамках бізнес-транзакції, конектор публікує в брокер → виключає «подвійний запис «/втрату.
Кореляційні метадані: `message_id`, `trace_id`, `causation_id`, `tenant_id`.

RPC через брокер (коли потрібно)

Запит публікується з'reply _ to'і'correlation _ id', відповідь - в зазначену чергу.
Використовувати обмежено (зовнішні провайдери, синхронні перевірки), контролювати таймаути і тенденцію до чату (інакше - деградація в розподілений моноліт).
Для гарячих призначених для користувача шляхів краще асинхронні події + проекції стану.

Контракти даних і схеми

Формати: Avro/Protobuf/JSON-Schema. Для JSON - фіксуйте версіонування і обов'язкові поля.
Політика еволюції: backward-compatible зміни; заборонені ламаючі зміни без міграцій.
PII - токенізація/шифрування полів; призначення (purpose) і термін зберігання.

Обробка помилок, ретраї, DLQ

Класифікація: тимчасові (мережеві/5хх) → ретраї; фатальні (валідація/схема) → DLQ.
Exponential backoff + jitter, обмеження числа спроб, мітки «poison-pill».
Відкладена доставка: через TTL/Delayed-exchange.
Інструмент «реінжект в роботу» з DLQ після фіксу причини.

Спостережуваність і SLO

Метрики продьюсера: швидкість публікації, помилки/підтвердження.
Метрики черг: довжина, швидкість споживання, відсоток ретраїв, p99 часу в черзі.
Консьюмери: lag, throughput, час обробки, частка NACK.
SLO: p99 E2E-латентність доставки події ≤ X секунд; доступність ≥ 99. 9%; DLQ-rate ≤ Y%.
Трейсинг: наскрізні'trace _ id '/' span _ id', логи по'message _ id'.
Алерти: зростання DLQ/лагів, падіння кворуму, сплеск NACK, «залипання» retry-стадій.

Безпека та доступи

TLS/MTLS в транзиті; шифрування на диску при зберіганні персистентних черг.
RBAC/ACL: права на publish/consume за vhost/namespace/топіку.
Сегментація: чутливі домени (платежі/КУС) - окремі обмінники/кластери.
Секрети в Vault/SOPS; аудит-лог публікацій/підписок.
Локалізація даних: зберігання і ретеншн по регіонах (ЄС, Туреччина, ЛатАм).

Висока доступність і DR

Кворумні черги/реплікація, непарне число нод, анти-афініті по AZ.
Міжрегіональна реплікація (federation/shovel) для критичних доменів.
Регламенти перемикання (runbook), періодичні DR-навчання (game day).
Версіонування топологій як код (IaC) - повторювані деплої і швидкий ресинк.

Продуктивність і тюнінг

Продьюсер: батч-підтвердження (publisher confirms), повторне використання каналів, асинхронні публікації.
Черги: prefetch під середню тривалість задачі; lazy для глибоких беклогів; рознос «гарячих» черг по нодах.
Мережа/OS: 10/25G, file descriptors, TCP-тюнінг. JVM/GC - під навантажувальний профіль.
Тести на burst-навантаження (матчі, турніри, пікові виплати).

Типові патерни маршрутизації для iGaming

1. Події платежів (topic):

Exchange: `payments. topic`

• `payments. psp. stripe. succeeded`
• `payments. psp..failed`
• `withdrawal. requested. #`

• `ledger. writer. q'( бінд: `payments. #`)
• `crm. triggers. q'( бінд: `payments...succeeded`)
• `risk. reviews. q'( бінд: `withdrawal. #`)

2. Антифрод-скоринг (direct + retry):

`risk. work. q` ← `risk. direct` (`routing_key=risk. check`)

`risk. retry. 1m. q'( TTL 60s → DLX назад в'risk. direct`)

`risk. dlq. q'для фатальних.

3. Нотифікації (fanout + пріоритет):

`notify. fanout` → `email. q (prio)`, `sms. q`, `push. q`

Пріоритети: висновки/ліміти вище маркетингових розсилок.

4. Аудит і трасування (headers):

Біндинги за заголовками'{ «tenant»:"X","critical":«true»}'→ окрема аудит-черга.

Приклад мінімальної схеми повідомлення (JSON)

json
{
"message_id": "01HX8H8Y6D6W0T1S2A3B4C5D6E",
"trace_id": "f4d2a1...e9",
"occurred_at": "2025-11-05T11:20:45. 321Z",
"tenant_id": "eu-1",
"schema_version": 3,
"event": "payments. psp. stripe. succeeded",
"payload": {
"payment_id": "pay_123",
"player_id": "p_987",
"amount": { "currency": "EUR", "value": 50. 00 },
"psp_tx": "tx_456",
"idempotency_key": "ulid_..."
}
}

Інтеграція з іншими контурами

Стрімінг/аналітика: важливі теми можуть дублюватися в лігву шину (Kafka/Redpanda) для ретеншну і reprocessing.
Фічестор: події → онлайн-фічі (Redis) та офлайн-партії (Parquet/OLAP).
Сага-оркестрація: команди через direct/topic, події - pub/sub; компенсуючі кроки - як окремі повідомлення.

Чек-лист впровадження

1. Визначте доменні обмінники і стандарт ключів маршрутизації.
2. Спроектуйте work/retry/DLQ на кожен критичний потік.
3. Увімкніть publisher confirms,'prefetch', пріоритети і delay, де потрібно.
4. Введіть idempotency-key, outbox і кореляційні ID.
5. Затвердіть схеми даних і правила еволюції.
6. Налаштуйте TLS/RBAC, сегментацію по доменах/тенантах.
7. Задайте SLO і алерти (lag, DLQ-rate, p99).
8. Підготуйте DR-план і автоматизовані IaC-топології.
9. Проведіть навантажувальні та chaos-тести.
10. Документуйте runbook для інцидентів і re-inject з DLQ.

Антипатерни

Один «гігантський» обмінник без дисципліни ключів; випадкові біндинги «як доведеться».
Відсутність retry/DLQ і змішування тимчасових/фатальних помилок.
Синхронний RPC поверх брокера на гарячих шляхах користувача.
Відсутність ідемпотентності і outbox → дублі/втрати грошей.
Зберігання PII у відкритому вигляді, загальний доступ publish/consume для всіх.

Підсумки

Добре спроектований Message Broker - це надійна артерія подій, де маршрутизація передбачувана, а відмовостійкість вбудована на рівні топології. Використовуйте topic-обмінники, єдиний стандарт ключів, work/retry/DLQ на кожен критичний потік, ідемпотентність і outbox, строгі SLO і спостережуваність. У тандемі зі стрімінговою шиною і проекціями стану це дає iGaming-платформі стійку швидкість, прозорість і контроль над складністю в міру зростання навантаження.