Multi-Brand-Casino-Architektur: Shared Services und Isolation

Vollständiger Artikel

💡 18+. Aufklärungsmaterial. Kein Aufruf zum Spiel. Der Fokus liegt auf dem Engineering und der Compliance von iGaming-Plattformen.

1) Aufgabe der Mehrmarkenplattform

Ein technologisches „Skelett“ bedient mehrere Marken/Lizenzen/Geo. Ziel ist ein Maximum an Kernel-Reuse (Geschwindigkeit, Selbstkosten) bei strikter Isolation von Risiken und Daten (Geld, PII, Reporting).

Die Schlüsselwahl: multi-tenant (allgemeine Instanzen, „Mieter“ innerhalb eines Dienstes) oder multi-instance (einzelne Instanzen/DB/Cluster pro Marke oder Region). In der Praxis kommt ein Hybrid zum Einsatz.

2) Schichten und Grenzen (Referenzschema)

Edge / Governance

API-Gateway, WAF/Bot-Schutz, Geo-Filter, Tarife, Service-Mesh.

Tenant/Markenresolver: Markenmetadaten (Lizenz, Geo, Währung, Flaggen).

Domain Core (nach Service)

PAM (Accounts, Sessions, 2FA) ist ein Multi-Tenant mit starrer tenant_id.

Wallet/Ledger (Buchhaltung) - häufiger Multi-Instance pro Lizenz/Region.

Cashier/PSP Orchestration - Einzelne Pipelines/Schlüssel pro Marke/Region.

KYC/AML sind Plug-in-Anbieter nach Geo, Regeln auf Tenant-Ebene.

Bonus Engine/Turniere/Jackpots sind Shareable Services mit Regelisolierung.

Game Gateway ist ein gemeinsames Gateway zu Anbietern mit Mapping von Fich/Währungen nach Marken.

Affiliates/Commission - allgemeine Mathematik, getrennte Tracking-Räume.

RG - Limits und Status auf Marken-/Jurisdiktionsebene, synchrone Bremsleuchten.

Compliance/Reporting - Schaufenster und Uploads pro Marke/Lizenz/Region.

CMS/Front - allgemeine Tools + Pro-Brand-Themen/Navigation.

Data & Observability

Ereignisbus (Kafka/Pulsar) mit den Schlüsseln 'tenant _ id/brand _ id'.

OLTP pro Service, OLAP-Schaufenster mit harter Row-Level-Isolierung nach Marke.

Metriken/Traces/Logs mit obligatorischen Tenant-Tags; SIEM/SOAR.

3) Wo zu teilen und wo zu isolieren

3. 1 Shared Services (Einsparungen und Geschwindigkeit)

Game Gateway: einheitliche Integrationen mit Studios, Fichflags per Brand.

Bonus/Tournament Engine: Allgemeiner Designer, aber „Sandboxen“ und Grenzen pro Marke.

Affiliates/Tracking: eine einzige Plattform, getrennte Sub-IDs/Domains/Postbacks.

KYC/Screening Orchestrator: gemeinsamer Bus, verschiedene Anbieter nach Geo.

CMS/Front Toolkit: Themen/Lokalisierung/Widgets; von der Front getrennt vom Kern.

BI/ETL: Allgemeine Pipelines, separate Schaufenster und Rechte.

3. 2 Harte Isolation (Geld, Recht, persönliche Daten)

Ledger/Wallet: einzelne DBs/Instances pro Lizenz/Region (oft sogar ein separater Cluster).

Cashier/PSP: Schlüssel, Merchants, Routing und Limits pro Marke/Region.

PII/Wohnsitz: Benutzerdaten werden in der Region gespeichert; Verbot von regionalübergreifenden Anfragen.

Compliance/Reporting: Regulatorische Entladungen streng nach Marke/Lizenz.

RG/AML: Bremsleuchten werden „vor Ort“ eingesetzt, ohne intertenante Scharfstellung.

4) Datenmultitenantenne Modelle

1. Schema-per-tenant: eine DB, getrennte Schaltungen. Einfach anfangen, schwieriger zu skalieren.

2. DB-per-tenant: einzelne DBs (oder Cluster) pro Marke/Region. Teurer, aber sicherer.

3. Table-partitioning by tenant: Große Tabellen mit harter RLS/Maskierung; geeignet für Telemetrie/Logs.

4. Storage-per-jurisdiction: physischer Wohnsitz (EU, UK, BR...), interregionaler Zugang auf dem Netzwerk/ACL verboten.

Für Ledger wird in der Regel DB-per-license/region + separate Service Layer gewählt.

5) Geldkreislauf: Invarianten und Ereignisse

Atomarität und Idempotenz von Kommandos ('wallet. debit/credit/settle') ist ein Schlüsselvertrag.

Outbox/CDC: Veröffentlichung von Ereignissen synchron zur Transaktion; Keine „manuelle Magie“.

Sagas: Einzahlung/Cashout/Bonus - nur durch Orchestrierung, Kompensation durch Einzelveranstaltungen.

Getrennte Jackpot-Geldbörsen und transparente Beiträge pro Marke/Pool.

SLO für Kernel (Minimum):

Geldbeutel p95 <150 ms; verlorene/duplizierte Settlemente = 0.
Cashier Autorisierung <3 s; Erfolg der Einzahlung ≥ 85% auf das Ziel geo.
Event-Zustellung in BI ≤ 5 Min.

6) Zahlungsorchestrierung in einer Multimarke

Piplines per brand/market: Verschiedene PSPs, Merchants, Limits, 3-DS Richtlinien.

Kaskadierung: Fallback →, ohne den Korb zu verlieren.

FinOps: Routen zu Kosten/Umbauten; Markenabstimmungsberichte täglich.

Anti-Betrug: Velocity, graphische Verknüpfungen von Karten/Geräten innerhalb der Marke und der Holding (mit vorsichtiger Kreuzkorrelation).

7) Verantwortungsvolles Spielen und Compliance

RG-Limits (Deposit/Loss/Time/Rate) - per Brand/Jurisdiktion konfigurierbar, synchron auf die Rate angewendet.

Selbstausschluss und Reality-Checks - respektieren die Markengrenzen und das Recht der Region.

AML/KYC - Sanktionslisten/RER/Geldquelle; SAR/STR nach Marke.

Berichterstattung - automatisiert; manuelle Excel sind als Prozess verboten.

8) Beobachtbarkeit und Zugänge

Trace-ID Ende-zu-Ende + Tags' tenant _ id/brand _ id/license'.

RBAC/ABAC: die Rollen "finansy/risk/sapport/marketing/komplajens" - der Zugang nur zur Handelsmarke.

Audit WORM: unveränderliche Protokolle von Kreta-Aktionen, die Politik der „vier Augen“.

Geheimnisse/Schlüssel: Vault/HSM, Schlüsselsegmentierung nach Marke/Region, Rotation.

9) Deploy Topologien

Single Cluster, Multi-Tenant Services

Schneller Start, knappe Einsparungen. Erfordert ausgereiftes RLS, Ressourcenisolierung und Limits.

Regional Clusters + Shared Integrations

Das Spielgateway und ein Teil der allgemeinen Dienste fummeln herum, Geld/PII ist regional. Balance von Kosten und Compliance.

Per-Brand/License Stacks

Vollständige Isolation (VIP-Marken, hohe Risiken). Teuer, aber minimal blast radius.

Oft kombiniert: eine gemeinsame „Schicht“ von Integrationen und Instrumenten + isoliertes Geld/PII.

10) Über Daten und Kataloge

Data contracts: Avro/JSON Schema + Registry; Semantische Versionen.

Governance: Feldkatalog, Besitzer, Schaufenster SLA, Abstammungslinie (Lineage).

RLS/Masking: Regeln auf Speicher- und BI-Ebene; Zugang zu PII - auf Antrag und Zeit-Token.

Late arrivals/dedup: nachhaltige Upsert-Muster in OLAP.

11) Marketing, CMS und Affiliates

Feature Flags per brand: Veröffentlichung von Promo/Themen/Mechanik ohne Quereffekte.

Inhaltsverzeichnisse: einheitliche Anbieter/Spiele-IDs, Mapping-Verfügbarkeit pro Marke/Markt.

Affiliates: getrennte Domains/UTM/Sub-ID; Anti-Betrug an Sub-Partnern.

Plattform-Compliance (YouTube/Twitch): Kennzeichnung von Anzeigen/Affiliates per Marke.

12) Reifegradmetriken der Mehrmarkenarchitektur

1. Isolierung des Geldes: einzelne DB/Instanzen pro Lizenz/Region; keine manuelle Bearbeitung.

2. Datenresidenz: technisch abgesichert (ACL/Netzwerkrichtlinien), durch Übungen verifiziert.

3. Event: outbox/CDC überall; Ströme erreichen BI ≤ 5 min.

4. Zahlungen: PSP-Kaskade aktiv; Abstimmungsberichte werden automatisiert.

5. RG/AML: Bremsleuchten werden synchron angelegt; Berichte ohne manuelle Schritte.

6. Observability: alle Metriken/Logs/Traces sind mit Brand/Tenant gekennzeichnet; SLO Dashboards für Dienstleistungen und Marken.

7. Zugänge: RBAC/ABAC und „vier Augen“ zum Kreta-Betrieb, WORM-Audit.

8. DR-Plan: RPO ≤ 5 min, RTO ≤ 30 min; regelmäßige Übungen für jede Region.

13) Architekten-Checkliste (vor Markeneinführung)

'brand _ id/tenant _ id' zugeordnet, Schlüssel/Geheimnisse und Grenzen gesetzt.
Ledger/Wallet - dedizierte Datenbank/Cluster (falls lizenzpflichtig).
Cashier - Merchant-Konten und Routen; Testtransaktionen und Abstimmungen.
RG/AML/KYC - Anbieter, Vorschriften, Bremslichter; Testszenarien.
Game Gateway - Mapping von Anbietern/Währungen/Beschränkungen; Gesundheitscheck.
Bonus/Turnier - Sandbox und Regelprüfung.
Affiliates - Sub-Space, Postbacks, Anti-Betrug.
CMS/Front - Thema, Lokalisierung, Fichflags; Geo-Beschränkungen überprüfen.
BI/Reports - Schaufenster, Zugänge, regulatorische Entladungen.
Beobachtbarkeit - SLO Dashboards und Alerts nach Marke/Region.

14) Rote Fahnen (das bricht die Multimarke)

Eine einzige DB „für alle“ ohne RLS/Maskierung und ohne separaten Ledger.

Manuelle Bearbeitungen von Salden, Boni und Limits.

Gemeinsame Merchant-PSP-Schlüssel für verschiedene Marken/Regionen.

Veröffentlichung von Ereignissen „vorbei“ an Domain-Transaktionen (keine Outbox/CDC).

BI/Berichte über Kampf-OLTP-Tabellen.

Keine Geo-Isolation von PII und DR-Übungen.

Die RG/AML-Regeln werden ohne Berücksichtigung des lokalen Rechts zwischen den Marken aufgeteilt.

Keine Tenant/Brand-Tags in Logs und Metriken - Untersuchungen werden zum Chaos.

15) Das Ergebnis

Die Multi-Brand-Architektur ist eine Balance aus Gemeinsamem und Getrenntem. Gemeinsame Integrationen, Instrumente und Entwicklungen beschleunigen die Entwicklung; isoliertes Geld, Zahlungen, PII und Berichterstattung halten die Compliance aufrecht und reduzieren die Risiken. Eine erfolgreiche Plattform basiert auf drei Prinzipien:

1. Monetäre Integrität und Isolation (Ledger/Cashier per license/region, idempotence, sagas).

2. Ereignis- und Beobachtbarkeit (Reifen, Verträge, Marken/Tenant-Tags, SLO).

3. Rechtlicher Wohnsitz und Zugang auf ein Minimum (RBAC/ABAC, WORM-Audit, KMS/Vault).

Eine solche Grundlage ermöglicht es, das Markenportfolio ohne exponentielles Komplexitätswachstum zu skalieren - schnell, sicher und vorhersehbar.