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

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

💡 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 - санклісти/РЕР/джерело коштів; 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).

Такий фундамент дозволяє масштабувати портфель брендів без експоненціального зростання складності - швидко, безпечно і передбачувано.