Черги повідомлень: Kafka и RabbitMQ

Черги повідомлень: Kafka, RabbitMQ

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

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

• Apache Kafka - розподілений журнал подій (log), орієнтований на потокову обробку, реплікацію і горизонтальний скейлінг через партії.
• RabbitMQ - брокер черг AMQP з гнучкою маршрутизацією (exchanges/bindings), пріоритетами, TTL, підтвердженнями і класичними завданнями черг.

Обидва інструменти зрілі, але вирішують різні завдання: Kafka - для масштабованих стрімів і аналітики, RabbitMQ - для оперативної оркестрації завдань, RPC і різноманітної маршрутизації.

Де що доречно в iGaming

• Потрібні високі TPS подій (ставки, ігрові події, телеметрія) і горизонтальний скейл через партії.
• Важливий холодний/гарячий ре-консюм (повторне читання стрічкових даних), ретеншн і компакшн для агрегатів (баланс, стан гравця).
• Потрібні стрім-процеси (Kafka Streams/ksqlDB/Flink) для realtime-агрегатів: лідери турнірів, ліміти відповідальної гри, антифрод-сигнали.

• Потрібні класичні черги завдань: KYC-перевірка, відкладені/повторні виплати, відправка e-mail/SMS/push, webhooks до PSP.
• Гнучка маршрутизація (topic/direct/fanout), пріоритети, TTL, delay, dead-letter і RPC-патерни.
• Потрібні строгі per-consumer обмеження (prefetch/QoS), просте управління навантаженням і швидкі ретраї.

Частий підсумок: Kafka для подій та аналітики + RabbitMQ для оркестрації та інтеграцій.

Модель даних і маршрутизація

Kafka

Топіки → розбиваються на партії, кожна - впорядкований лог.
Ключ повідомлення визначає партію → впорядкованість в рамках ключа.
Консьюмери читають по offset, групи консьюмерів масштабують обробку.
Ретеншн за часом/обсягом; log compaction зберігає останню версію ключа.

RabbitMQ

Exchanges (direct/fanout/topic/headers) + bindings → повідомлення потрапляють в queues.
Підтвердження (ack/nack/requeue), publisher confirms, priorities, TTL, dead-letter (DLX/DLQ).
Quorum queues (Raft) для високої доступності; lazy queues для економії RAM.

Гарантії доставки та ідемпотентність

At-most-once: без ретраїв; ризик втрат, мінімальна затримка.
At-least-once: стандарт за замовчуванням → можливі дублікати → ідемпотентні хендлери (ключ запиту/транзакції, upsert, dedup-таблиця, outbox).
Exactly-once: в Kafka досягається в зв'язці ідемпотентний продьюсер + транзакційні топіки + узгоджене споживання, але частіше дорожче і складніше; в RabbitMQ - обмежено і з кістками. У реальних платіжних/ставкових потоках застосовується at-least-once + сувора ідемпотентність.

• Унікальні idempotency-keys (UUID/ULID) на подію/команду.
• Outbox-патерн в БД сервісу + Change Data Capture (Debezium) → запобігання «подвійного запису».
• Dedup по (key, created_at) в окремому сторі з TTL.

Замовлення/порядок повідомлень

Kafka гарантує порядок всередині партії. Ключ вибирайте так, щоб в одному ключі виявилося все «життя» сутності (наприклад,'player _ id'для балансу).
RabbitMQ порядок не строго гарантований при повторних доставках/декількох консьюмерів; критичні до порядку пайплайни - краще в Kafka або через single-active consumer і серіалізацію потоку.

Проектування топіків і черг

• Гранулярність: `domain. event'( наприклад,'payments. deposit. created`).
• Ключі: 'player _ id','account _ id','bet _ id'для впорядкованості.
• Партій = N за цільовою TPS (правило: 1 партія ≈ X повідомлень/сек/консюмер); закладати запас на зростання.
• Ретеншн: події - години/дні; компакшн - для «станів».

• Exchanges по доменах: `payments. direct`, `risk. topic`.
• Черги під споживачів: `kyc. checker. q`, `psp. webhooks. retry. q`.
• DLQ на кожну робочу чергу; delay для backoff.
• Prefetch задає паралелізм, черги quorum - для HA.

Помилки, ретраї та DLQ

Класифікуйте помилки: тимчасові (мережеві/PSP 5xx) → ретраї; фатальні (валідація, схема) → відразу DLQ.
Exponential backoff + jitter, ліміт ретраїв, «poison-pill» детектування.
Окремі retry-queues по кроках (5s, 1m, 5m, 1h).
DLQ-обробник: алерт, трейс, ручний розбір, ре-інжект з патчем.

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

Використовуйте Avro/Protobuf + Schema Registry (для Kafka - стандарт де-факто).
Версіонування: backward-compatible зміни (додавання опціональних полів), заборона на ламаючі міграції.
Поля PII - шифрування/токенізація; дотримуйтесь GDPR та локальних норм.

Моніторинг, спостережуваність і SLO

Метрики продьюсерів/консьюмерів: lag, throughput, помилки, ретраї, час обробки.
Логи + трейсинг (кореляційні ID: `trace_id`, `message_id`).
SLO: p99-латентність публікації/доставки, допустимий consumer lag, час відновлення після фейлів.
Алерти на зростання DLQ, перевищення lag, падіння партій/кворуму.

Безпека та комплаєнс

TLS в транзиті, шифрування секретів (SOPS/Vault), обмежені ACL/RBAC.
Окремі топіки/черги для чутливих доменів (платежі, KYC).
Аудит-лог публікацій/підписок, зберігання ключів поза кодом.
Регіональні вимоги (EU/Туреччина/ЛатАм): ретеншн, локалізація зберігання, маскування.

Висока доступність, відмовостійкість і DR

• Кластер 3-5 брокерів мінімум; replication. factor ≥ 3.
• min. insync. replicas і acks = all для міцних записів.
• Крос-регіональні реплікації (MirrorMaker-2) для DR.

• Quorum queues для HA, парне/непарне число нод з кворумом.
• Federation/Shovel для міжЦОД реплікації, DR-сценаріїв.
• Холодний/теплий стенд, тести перемикання.

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

• `linger. ms` и `batch. size'для батчингу;'compression. type` (lz4/zstd).
• 'acks = all', але стежити за латентністю; тюн'max. in. flight. requests. per. connection'з ідемпотентністю.

• Достатньо партій; диски NVMe; сітка 10/25G; GC-налаштування JVM.

• Правильний group management,'max. poll. interval. ms', паузити партії при бекофі.

• Publisher confirms в батчах; channels перевикористовувати.

• 'prefetch'( напр. 50-300) за часом обробки; lazy queues для великих беклогів.
• Розносити гарячі черги по нодах; тюн ТСР/файлові дескриптори.

Типові патерни для iGaming

Outbox + Kafka для надійної публікації доменних подій (ставка розміщена, депозит зарахований).
RabbitMQ RPC для синхронних запитів до інтеграцій (перевірка документа KYC, розрахунок бонусу).
Сага-патерн: оркестрація через події (Kafka) і команди (RabbitMQ) з компенсуючими кроками.
Fan-out повідомлень: з однієї події → CRM, антифрод, аналітика.
Smart-retry PSP-вебхуків з прогресивними затримками і DLQ.

Міграція та гібридні архітектури

Почніть з RabbitMQ для «операційки», додайте Kafka для подій та аналітики.
Дублюйте публікації: сервіс → outbox → конектор в обидві сторони (Kafka + RabbitMQ) до повної стабілізації.
Поступово переносьте передплатників аналітики/стрім-агрегацій на Kafka Streams/ksqlDB.

Міні-чек-лист вибору

1. Навантаження/TPS> десятків тисяч/сек? → Kafka.
2. Потрібен ретеншн і повторне читання як з журналу? → Kafka.
3. Гнучка маршрутизація, пріоритети, відкладена доставка, RPC? → RabbitMQ.
4. Строгий порядок по ключу і горизонтальний скейл → Kafka (ключ/партії).
5. Прості завдання/ворк-кью з управлінням паралелізмом → RabbitMQ.
6. В ідеалі - комбінація: Kafka (події) + RabbitMQ (оркестрація).

Приклади мінімальних конфігурацій

Приклад: затримані ретраї і DLQ в RabbitMQ (через policy)

Робоча черга: `psp. webhooks. q`

Черга ретраїв: `psp. webhooks. retry. 1m. q'( TTL = 60s, DLX вказує назад на робочу)

DLQ: `psp. webhooks. dlq`

• `psp. webhooks. q` → `x-dead-letter-exchange=psp. retry. exchange`
• `psp. webhooks. retry. 1m. q` → `x-message-ttl=60000`, `x-dead-letter-exchange=psp. work. exchange`
• `psp. webhooks. dlq'→ моніторинг і ручний розбір.

Приклад: топік Kafka для ставок

Топік: `bets. placed. v1', партії: 24, RF = 3, ретеншн 7 днів.
Ключ повідомлення: 'player _ id'або'bet _ id'( виберіть, що важливіше для порядку).
Схема: Protobuf/Avro с `bet_id`, `player_id`, `stake`, `odds`, `ts`, `idempotency_key`.

Тестування та якість

Contract-тести продьюсер/консьюмер + перевірки схем (Schema Registry).
Chaos-тести: падіння нод, затримки мережі, split-brain.
Навантажувальні прогони з цільовим TPS, перевірка p99, зростання lag і відновлення.

Підсумки

Kafka - магістраль подій і стрімінг: впорядкованість по ключу, ретеншн/компакшн, високі TPS, аналітика в реальному часі.
RabbitMQ - операційна черга завдань: гнучка маршрутизація, підтвердження, пріоритети, ретраї/DLQ, RPC.
В iGaming найкраща практика - комплементарне використання: події та аналітика в Kafka, інтеграційні/оркестраційні завдання в RabbitMQ, з єдиними стандартами схем, ідемпотентністю, моніторингом і строгими SLO.