Чому iGaming переходить на мікросервіси

Повний текст статті

1) Контекст: чому моноліт перестав працювати

iGaming зростає за контентом, географіями і регуляціями. Монолітна кодова база:

• гальмує релізи (загальні деплой-вікна, ризик регресій), погано масштабується (гаманець і каса - гарячі, а CMS - холодна), заважає відповідності вимогам (різні регулятори → різні правила даних), ускладнює ізоляцію грошей (money-flows і бонуси переплетені).

Підсумок - високі ризики інцидентів і повільний time-to-market.

2) Що дає мікросервісний підхід

1. Ізоляція критичних доменів. Гаманець/Ledger, Cashier/PSP, Bonus Engine, Game Sessions, KYC/AML, RG, Risk/Fraud, Affiliates, CRM - окремі сервіси зі своїми SLO.

2. Масштабування за споживанням. Гарячі сервіси (гаманець, каса, ігрова сесія) отримують більше ресурсів без роздування всього кластера.

3. Незалежні релізи. Команди деплоят по своєму циклу (канарські релізи, feature-прапори).

4. Стійкість до збоїв. Локальна деградація не валить весь продукт (cashier деградує - ігри тривають за рахунок кешів і черг).

5. Юридична сегментація. Рознос PII і платежів по регіонах (EU/UK/BR) і дата-резидентність.

6. Гнучкість інтеграцій. Паралельне підключення провайдерів ігор, PSP і KYC-провайдерів.

3) Базова схема (спрощено)

Edge шар: API Gateway, WAF/бот-захист, rate limiting, geo-фільтри.

Доменні мікросервіси: Wallet/Ledger, Bonus, Cashier, Game Gateway, Risk/Fraud, RG, KYC/AML, Affiliates, CRM, CMS, Reporting/Compliance.

Подієва шина: Kafka/Pulsar — `bet. placed`, `bet. settled`, `wallet. debit/credit`, `cashier. deposit. succeeded`, `rg. limit. hit`, `bonus. consumed'і т.п.

Дані: OLTP БД на сервіс, outbox/CDC → DWH (ClickHouse/BigQuery).

Observability: метрики/логи/трейси; SIEM/SOAR; audit-log WORM.

4) Гроші і цілісність: чому це ключ до міграції

Головний аргумент «за» мікросервіси - жорстка ізоляція грошового контуру:

• окремий Ledger зі строгим ACID та ідемпотентністю команд, саги для довгих процесів (депозити, кешаут, бонусні нарахування), outbox + транзакційна публікація подій, нульовий допуск «ручних правок» балансів.

Такий дизайн знижує ймовірність втрати/дублювання сеттлментів до нуля на архітектурному рівні.

5) Патерни, без яких мікросервіси не злетять

CQRS + проекції. Команди - строго через доменні API; читання - через проекційні моделі.

Idempotency Keys. Кожна грошова/бонусна команда повторюється без побічних ефектів.

Саги і компенсації. Явні компенсуючі події замість «відкату БД».

Schema Registry. Версіонування контрактів подій; сумісність продюсерів/консьюмерів.

Rate limits/Retry/Backoff. Мережеві збої - це норма; клієнтська стійкість.

Zero-trust і секрети. mTLS всередині mesh, Vault/HSM, мінімальні привілеї.

6) Що складніше в мікросервісах (чесно про мінуси)

Мережа дорожче пам'яті. Більше RPC, зростання латентності і вартість інфраструктури.

Складність даних. Консистентність - eventual за межами Ledgera, потрібні проекції.

Спостережуваність. Без наскрізного трасингу і SLO все швидко перетворюється в «чорний ящик».

Командна дисципліна. Контрактні тести, ритуали релізів, міграції схем - обов'язкові.

Крос-регіональні розриви. Data residency вимагає продуманої шардизації.

Якщо компанія не готова до DevOps/SRE-культури, моноліт «з хорошою модульністю» може бути кращим.

7) Покрокова міграція: від моноліту до сервісів

Крок 1. Стандартизуйте події. Введіть шину і єдиний словник: гравець, ставка, сеттлмент, депозит, бонус.

Крок 2. Винесіть Ledger. Грошовий контур відокремлюється першим: окрема БД, API команд, outbox.

Крок 3. Відокремте Cashier. Оркестрація PSP, каскади, 3-DS, звірки - як самостійний сервіс.

Крок 4. Game Gateway. Єдиний шлюз до провайдерів ігор; сесії/коллбеки - не через моноліт.

Крок 5. Bonus Engine и RG. Правила, вейджер, ліміти - автономно, підписка на події гаманця/ігор.

Крок 6. Risk/AML + KYC. Окремий контур зі своїми інтеграціями та алертингом.

Крок 7. Дані та BI. CDC в DWH, вітрини KPI, анти-Excel звітність.

Крок 8. Back-office. RBAC/ABAC, аудит-лог, «4 ока» для крит-екшенів.

Паралельно - канарські релізи, фічефлаги, rollback, регулярні DR-навчання.

8) Досвід експлуатації: які SLO вважати нормою

Аптайм ядра (wallet/cashier/game-gateway) ≥ 99,95%.

p95 латентності гаманця <150 мс; cashier авторизація <3 с.

«Втрачених/дубльованих сетлментів» = 0.

Доставка подій в BI-вітрини ≤ 5 хв.

MTTR по інцидентах ядра <30 хв.

9) Безпека та комплаєнс «за замовчуванням»

Сегментація PII/платіжних даних, PCI DSS, GDPR/локальні аналоги.

Шифрування at-rest/in-transit, короткоживучі токени, ротація ключів.

WAF/бот-захист, device-fingerprinting, аномалії по velocity.

Аудит-логи в WORM-сховищі, доступ за принципом найменших прав.

10) Економіка та організаційні ефекти

TTR релізів ↓: незалежні деплої зменшують черги завдань і контекст-світч.

Cost-to-scale ↓/↑: горизонтальне масштабування точково дешевше, але потрібен продуманий FinOps (автоскейл, ліміти, spot-інстанси).

Ризик інцидентів ↓: blast radius обмежений сервісом.

Продуктова швидкість ↑: нові провайдери/PSP і фічі не чекають «загального вікна».

11) Чек-лист зрілості мікросервісного iGaming-ядра

• Ledger - окремий сервіс і БД, тільки командний API, outbox/CDC.
• Всі грошові/бонусні операції ідемпотентні, ключі дедуплікації - скрізь.
• Шина подій з реєстром схем; backward-compatible контракти.
• Cashier з каскадом PSP і щоденними звірками.
• Game Gateway з деградацією «no new sessions» при інцидентах.
• RG/AML - синхронні стоп-сигнали на ставці, reality-checks.
• Observability: метрики/логи/трейси по наскрізному trace_id; дашборди SLO.
• DR-план: RPO ≤ 5 хв, RTO ≤ 30 хв; Регулярні навчання.
• Data residency і маскування PII; RBAC/ABAC і «4 ока».
• BI без ручних Excel: вітрини KPI, кохорти, LTV, звіти регуляторам.

12) Червоні прапори (антипатерни)

Ручні правки балансів/бонусів в БД.

Єдина БД «на все», BI б'є по бойовим таблицям.

Публікація подій «в обхід» транзакцій домену (немає outbox).

Відсутність версіонування схем подій.

Нульова ідемпотентність і ретраї «як вийде».

Платіжні відмови без каскаду і детальної телеметрії.

Немає RG/AML стоп-сигналів на критичних шляхах.

---

Мікросервіси в iGaming - не данина моді, а спосіб розвести гроші, ризик і продукт по незалежних контурах, прискорити релізи і знизити масштаб інцидентів. Ключ - грошова цілісність (Ledger + ідемпотентність + саги), подієвість (шина + контракти) і культура SRE/DevOps. При такому фундаменті платформа витримує зростання трафіку, географій і регуляторних вимог, залишаючись швидкою, прозорою і безпечною.