Почему 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 c деградацией «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. При таком фундаменте платформа выдерживает рост трафика, географий и регуляторных требований, оставаясь быстрой, прозрачной и безопасной.