Multi-brand casino architecture: shared services and isolation

Full article

💡 18+. Educational material. Not a call to play. The focus is on engineering and compliance of iGaming platforms.

1) Multi-brand platform task

One technological "skeleton" serves several brands/licenses/geo. The goal is the maximum core release (speed, cost) with strict isolation of risks and data (money, PII, reporting).

Key choice: multi-tenant (common instances, "tenants" within the same service) or multi-instance (individual instances/databases/clusters per brand or region). In practice, a hybrid is used.

2) Layers and boundaries (reference scheme)

Edge / Governance

API-gateway, WAF/bot protection, geo-filters, tariffs, service mesh.

Tenant/brand resolver: brand metadata (license, geo, currency, flags).

Domain Core (by service)

PAM (accounts, sessions, 2FA) - multi-tenant with hard tenant_id sharing.

Wallet/Ledger (accounting) - more often multi-instance per license/region.

Cashier/PSP Orchestration - separate pipelines/keys per brand/region.

KYC/AML - connected geo providers, tenant-level rules.

Bonus Engine/Tournaments/Jackpots - shareable services with isolation of rules.

Game Gateway is a common gateway to providers with mapping features/currencies by brand.

Affiliates/Commission - general mathematics, separate tracking spaces.

RG - limits and statuses at brand/jurisdiction level, synchronous brake lights.

Compliance/Reporting - showcases and uploads to brand/license/region.

CMS/Front - common tools + per-brand themes/navigation.

Data & Observability

Event bus (Kafka/Pulsar) with 'tenant _ id/brand _ id' keys.

OLTP to service, OLAP showcases with hard row-level insulation by brand.

Metrics/trails/logs with mandatory tenant tags; SIEM/SOAR.

3) Where to share and where to isolate

3. 1 Shared services (savings and speed)

Game Gateway: uniform integrations with studios, feature flags per brand.

Bonus/Tournament Engine: common constructor, but sandboxes and per brand limits.

Affiliates/Tracking: single platform, separate sub-IDs/domains/post-backs.

KYC/Screening Orchestrator: common bus, different geo providers.

CMS/Front toolkit: themes/localization/widgets; a depleted front separate from the nucleus.

BI/ETL: common pipelines, individual storefronts and rights.

3. 2 Strict isolation (money, law, personal data)

Ledger/Wallet: individual databases/instances per license/region (often even a separate cluster).

Cashier/PSP: keys, merchants, routing and limits per brand/region.

PII/Residency: user data is stored in the region; prohibition of cross-regional requests.

Compliance/Reporting: regulatory uploads strictly by brand/license.

RG/AML: brake lights are applied "in place," without inter-tenant sharing.

4) Data multitenancy models

1. Schema-per-tenant: one database, separate schemas. Just starting, harder to scale.

2. DB-per-tenant: individual databases (or clusters) per brand/region. More expensive, but safer.

3. Table-partitioning by tenant: large tables with hard RLS/masking; suitable for telemetry/logs.

4. Storage-per-jurisdiction: physical residency (EU, UK, BR...), interregional access is prohibited on the network/ACL.

For Ledger, DB-per-license/region + a separate service layer is usually chosen.

5) Money contour: invariants and events

Atomicity and idempotency of teams ('wallet. debit/credit/settle ') is a key contract.

Outbox/CDC: publishing events synchronous to transaction; no "hand magic."

Sagas: deposit/cashout/bonus - only through orchestration, compensation by individual events.

Separate jackpot wallets and transparent contributions per brand/pool.

SLO for core (minimum):

p95 wallet <150 ms; lost/duplicated settlements = 0.
Cashier authorization <3 s; deposit success ≥ 85% on target geo.
Event delivery to BI ≤ 5 min.

6) Multi-brand payment orchestration

Pipelines per brand/market: different PSPs, merchants, limits, 3-DS policies.

Cascading - Fail → fallback without losing the recycle bin.

FinOps: cost/conversion routes; brand reconciliation reports daily.

Anti-fraud: velocity, graph links of cards/devices within the brand and holding (with careful cross-correlation).

7) Responsible play and compliance

RG limits (deposit/loss/time/rate) - configured per brand/jurisdiction, applied synchronously on the rate.

Self-exclusion and reality checks - respect the boundaries of the brand and the law of the region.

AML/KYC - sanctions/PEP/source of funds; SAR/STR by brand.

Reporting - automated; manual Excel is not allowed as a process.

8) Observability and accesses

Trace-ID pass-through + tags' tenant _ id/brand _ id/license '.

RBAC/ABAC: role "finance/risk/support/marketing/compliance" - access only to the brand.

Audit WORM: unchangeable logs of Crete actions, four-eye policy.

Secrets/keys: Vault/HSM, key segmentation by brand/region, rotation.

9) Deploy topologies

Single Cluster, Multi-Tenant Services

Fast start-up, tight economy. Requires mature RLS, resource isolation, and limits.

Regional Clusters + Shared Integrations

The game gateway and some of the general services are rummaged, money/PII - regionally. Balance of cost and compliance.

Per-Brand/License Stacks

Complete isolation (VIP brands, high risks). Expensive, but minimal blast radius.

Often combined: a common "layer" of integrations and instruments + isolated money/PII.

10) About data and catalogs

Data contracts: Avro/JSON Schema + Registry; semantic versions.

Governance: field catalog, owners, SLA storefronts, lineage.

RLS/Masking - Storage and BI level rules access to PII - by application and time token.

Late arrivals/dedup: stable upsert patterns in OLAP.

11) Marketing, CMS and Affiliates

Feature Flags per brand: release of promo/themes/mechanic without cross effects.

Content catalogs: uniform IDs of providers/games, mapping availability to brand/market.

Affiliates: separate domains/UTM/sub-ID; anti-fraud on sub-partners.

Platform compliance (YouTube/Twitch): Ad/affiliate labeling per brand.

12) Multi-brand architecture maturity metrics

1. Isolation of money: separate databases/instances per license/region; zero manual edit.

2. Data residency: technically supported (ACL/network policies), verified by exercises.

3. Eventfulness: outbox/CDC everywhere; flows reach BI ≤ 5 min.

4. Payments: PSP cascade active; reconciliation reports are automated.

5. RG/AML: brake lights are applied synchronously; reporting without manual steps.

6. Observation: all metrics/logs/trails are marked brand/tenant; dashboards SLO by services and brands.

7. Accesses: RBAC/ABAC and "four eyes" on crete operations, WORM audit.

8. DR-plan: RPO ≤ 5 min, RTO ≤ 30 min; regular exercises for each region.

13) Architect checklist (before brand launch)

Assigned 'brand _ id/tenant _ id', keys/secrets and limits.
Ledger/Wallet - dedicated database/cluster (if required by license).
Cashier - merchant accounts and routes; test transactions and reconciliations.
RG/AML/KYC - providers, rules, brake lights; test scenarios.
Game Gateway - mapping providers/currencies/restrictions; health-check.
Bonus/Tournament - sandbox and rule audit.
Affiliates - sub-space, post-backs, anti-fraud.
CMS/Front - theme, localization, feature flags; geo-constraint checking.
BI/Reports - showcases, accesses, regulatory uploads.
Observability - SLO dashboards and alerts by brand/region.

14) Red flags (what breaks the multi-brand)

A single database "for all" without RLS/masking and without a separate Ledger.

Manual adjustments to balances, bonuses, and limits.

Common PSP merchant keys for different brands/regions.

Publishing events "past" domain transactions (no outbox/CDC).

BI/reports on combat OLTP tables.

Lack of geo-isolation of PII and DR exercises.

RG/AML rules are shared between brands without taking into account local law.

There are no tenant/brand tags in logs and metrics - investigations turn into chaos.

15) The bottom line

Multi-brand architecture is a balance of common and separate. Common integrations, tools and events accelerate development; isolated money, payments, PII and reporting preserve compliance and reduce risks. A successful platform is built around three principles:

1. Monetary integrity and isolation (Ledger/Cashier per license/region, idempotency, sagas).

2. Event and observability (bus, contracts, brand/tenant tags, SLO).

3. Legal residency and minimum access (RBAC/ABAC, WORM audit, KMS/Vault).

This foundation allows the portfolio of brands to scale without exponential growth in complexity - quickly, safely and predictably.