Мультибрендовая архитектура казино: общие сервисы и изоляция

Полный текст статьи

💡 18+. Просветительский материал. Не призыв к игре. Фокус — на инженерии и комплаенсе iGaming-платформ.

1) Задача мультибрендовой платформы

Один технологический «скелет» обслуживает несколько брендов/лицензий/гео. Цель — максимум реюза ядра (скорость, себестоимость) при строгой изоляции рисков и данных (деньги, PII, отчётность).

Ключевой выбор: multi-tenant (общие инстансы, «арендаторы» в рамках одного сервиса) или multi-instance (отдельные инстансы/БД/кластеры на бренд или регион). На практике используется гибрид.

2) Слои и границы (эталонная схема)

Edge / Governance

API-gateway, WAF/бот-защита, гео-фильтры, тарифы, сервис-mesh.

Tenant/brand resolver: метаданные бренда (лицензия, гео, валюта, флаги).

Domain Core (по сервисам)

PAM (аккаунты, сессии, 2FA) — multi-tenant с жёстким разделением tenant_id.

Wallet/Ledger (бухгалтерия) — чаще multi-instance per license/region.

Cashier/PSP Orchestration — отдельные пайплайны/ключи на бренд/регион.

KYC/AML — подключаемые провайдеры по гео, правила на tenant-уровне.

Bonus Engine / Tournaments / Jackpots — shareable сервисы с изоляцией правил.

Game Gateway — общий шлюз к провайдерам с маппингом фич/валют по брендам.

Affiliates/Commission — общая математика, раздельные трекинг-пространства.

RG — лимиты и статусы на уровне бренда/юрисдикции, синхронные стоп-сигналы.

Compliance/Reporting — витрины и выгрузки на бренд/лицензию/регион.

CMS/Front — общие инструменты + per-brand темы/навигация.

Data & Observability

Шина событий (Kafka/Pulsar) с ключами `tenant_id/brand_id`.

OLTP на сервис, OLAP витрины с жёсткой row-level изоляцией по бренду.

Метрики/трейсы/логи с обязательными tenant-тегами; SIEM/SOAR.

3) Где делиться, а где изолировать

3.1 Общие сервисы (экономия и скорость)

Game Gateway: единые интеграции со студиями, фич-флаги per brand.

Bonus/Tournament Engine: общий конструктор, но «песочницы» и лимиты per brand.

Affiliates/Tracking: единая платформа, раздельные саб-ID/домены/постбэки.

KYC/Screening Orchestrator: общая шина, разные провайдеры по гео.

CMS/Front toolkit: темы/локализация/виджеты; деплой фронта отдельно от ядра.

BI/ETL: общие пайплайны, отдельные витрины и права.

3.2 Жёсткая изоляция (деньги, право, персональные данные)

Ledger/Wallet: отдельные БД/инстансы на лицензию/регион (часто даже отдельный кластер).

Cashier/PSP: ключи, мерчанты, маршрутизация и лимиты per brand/регион.

PII/Резидентность: данные пользователей хранятся в регионе; запрет кросс-региональных запросов.

Compliance/Reporting: регуляторные выгрузки строго по бренду/лицензии.

RG/AML: стоп-сигналы применяются «на месте», без меж-тенантного шаринга.

4) Модели мультитенантности данных

1. Schema-per-tenant: одна БД, отдельные схемы. Просто стартовать, сложнее масштабировать.

2. DB-per-tenant: отдельные БД (или кластеры) на бренд/регион. Дороже, но безопаснее.

3. Table-partitioning by tenant: крупные таблицы с жёстким RLS/маскированием; подходит для телеметрии/логов.

4. Storage-per-jurisdiction: физическая резидентность (EU, UK, BR…), межрегиональный доступ запрещён на сети/ACL.

Для Ledger обычно выбирают DB-per-license/region + отдельный сервисный слой.

5) Денежный контур: инварианты и события

Атомарность и идемпотентность команд (`wallet.debit/credit/settle`) — ключевой контракт.

Outbox/CDC: публикация событий синхронна транзакции; никакой «ручной магии».

Саги: депозит/кэшаут/бонус — только через оркестрацию, компенсации отдельными событиями.

Раздельные джекпот-кошельки и прозрачные взносы per brand/пул.

SLO для ядра (минимум):

p95 кошелька < 150 мс; потерянных/дублированных сеттлментов = 0.
Cashier авторизация < 3 с; успех депозита ≥ 85% на целевом гео.
Доставка событий в BI ≤ 5 мин.

6) Платёжная оркестрация в мультибренде

Пайплайны per brand/market: разные PSP, мерчанты, лимиты, 3-DS политика.

Каскадирование: отказ → fallback без потери корзины.

FinOps: маршруты по стоимости/конверсии; отчёты сверки по брендам ежедневно.

Анти-фрод: velocity, графовые связи карт/устройств в пределах бренда и холдинга (с осторожной кросс-корреляцией).

7) Ответственная игра и комплаенс

RG-лимиты (депозит/потери/время/ставка) — конфигурируются per brand/юрисдикция, применяются синхронно на ставке.

Самоисключение и реальность-чеки — уважают границы бренда и закон региона.

AML/KYC — санклисты/PEP/источник средств; SAR/STR по бренду.

Отчётность — автоматизирована; ручные Excel запрещены как процесс.

8) Наблюдаемость и доступы

Trace-ID сквозной + теги `tenant_id/brand_id/license`.

RBAC/ABAC: роли «финансы/риск/саппорт/маркетинг/комплаенс» — доступ только к своему бренду.

Audit WORM: неизменяемые логи крит-действий, политика «четырёх глаз».

Секреты/ключи: Vault/HSM, сегментация ключей на бренд/регион, ротация.

9) Топологии деплоя

Single Cluster, Multi-Tenant Services

Быстрый запуск, плотная экономия. Требует зрелого RLS, изоляции ресурсов и лимитов.

Regional Clusters + Shared Integrations

Игровой шлюз и часть общих сервисов шарятся, деньги/PII — регионально. Баланс стоимости и комплаенса.

Per-Brand/License Stacks

Полная изоляция (VIP-бренды, высокие риски). Дорого, но минимальный blast radius.

Часто комбинируют: общий «пласт» интеграций и инструментов + изолированные деньги/PII.

10) Про данные и каталоги

Data contracts: Avro/JSON Schema + Registry; семантические версии.

Governance: каталог полей, владельцы, SLA витрин, линейка происхождения (lineage).

RLS/Masking: правила на уровне хранилища и BI; доступ к PII — по заявке и токену времени.

Late arrivals/dedup: устойчивые upsert-паттерны в OLAP.

11) Маркетинг, CMS и аффилиаты

Feature Flags per brand: выпуск промо/тем/механик без перекрёстных эффектов.

Каталоги контента: единые ID провайдеров/игр, маппинг доступности на бренд/рынок.

Аффилиаты: раздельные домены/UTM/саб-ID; анти-фрод на суб-партнёров.

Соблюдение платформ (YouTube/Twitch): маркировка рекламы/аффилиатов per brand.

12) Метрики зрелости мультибрендовой архитектуры

1. Изоляция денег: отдельные БД/инстансы на лицензию/регион; нулевая ручная правка.

2. Data residency: технически обеспечена (ACL/сетевые политики), проверена учениями.

3. Событийность: outbox/CDC везде; потоки достигают BI ≤ 5 мин.

4. Платежи: каскад PSP активен; отчёты сверки автоматизированы.

5. RG/AML: стоп-сигналы применяются синхронно; отчётность без ручных шагов.

6. Observability: все метрики/логи/трейсы помечены brand/tenant; дашборды SLO по сервисам и брендам.

7. Доступы: RBAC/ABAC и «четыре глаза» на крит-операции, WORM-аудит.

8. DR-план: RPO ≤ 5 мин, RTO ≤ 30 мин; регулярные учения по каждому региону.

13) Чек-лист архитектора (перед запуском бренда)

Присвоен `brand_id/tenant_id`, заведены ключи/секреты и лимиты.
Ledger/Wallet — выделенная БД/кластер (если требует лицензия).
Cashier — мерчант-аккаунты и маршруты; тестовые транзакции и сверки.
RG/AML/KYC — провайдеры, правила, стоп-сигналы; тестовые сценарии.
Game Gateway — маппинг провайдеров/валют/ограничений; health-чек.
Bonus/Tournament — песочница и аудит правил.
Affiliates — саб-пространство, постбэки, анти-фрод.
CMS/Front — тема, локализация, фичфлаги; проверка гео-ограничений.
BI/Reports — витрины, доступы, регуляторные выгрузки.
Наблюдаемость — дашборды SLO и алерты по бренду/региону.

14) Красные флаги (что ломает мультибренд)

Единая БД «для всех» без RLS/маскировки и без отдельного Ledger.

Ручные правки балансов, бонусов и лимитов.

Общие мерчант-ключи PSP для разных брендов/регионов.

Публикация событий «мимо» транзакций домена (нет outbox/CDC).

BI/отчёты по боевым OLTP-таблицам.

Отсутствие гео-изоляции PII и DR-учений.

RG/AML-правила расшарены между брендами без учёта локального закона.

Нет тегов tenant/brand в логах и метриках — расследования превращаются в хаос.

15) Итог

Мультибрендовая архитектура — это баланс общего и отделённого. Общие интеграции, инструменты и события ускоряют развитие; изолированные деньги, платежи, PII и отчётность сохраняют комплаенс и снижают риски. Успешная платформа строится вокруг трёх принципов:

1. Денежная целостность и изоляция (Ledger/Cashier per license/region, идемпотентность, саги).

2. Событийность и наблюдаемость (шина, контракты, теги brand/tenant, SLO).

3. Юридическая резидентность и доступы по минимуму (RBAC/ABAC, WORM-аудит, KMS/Vault).

Такой фундамент позволяет масштабировать портфель брендов без экспоненциального роста сложности — быстро, безопасно и предсказуемо.