Casino Core Architektur: Schichten, Module, Datenbusse

Vollständiger Artikel

💡 18+. Das Material ist aufklärerisch. Kein Aufruf zum Spiel. Ziel ist es, eine technische „Geländekarte“ für den Aufbau oder das Audit des iGaming-Kerns zu zeigen.

1) Das ganze Bild: Woraus besteht der Casino-Kern

Casino Core ist eine Reihe von Domain-Diensten, die die Registrierung/Identifizierung von Spielern, die Annahme/Speicherung von Geld, die Berechnung von Wetten, die Bonusökonomie, die Risikokontrolle und die Einhaltung der Vorschriften gewährleisten. Im Diagramm von oben nach unten:

1. Edge-Layer (Außenumfang): API-Gateway, WAF/Bot-Schutz, Rate-Limiting, Service-Mesh-Ingress, Geo/Legal-Filter.

2. Domain-слой (бизнес-логика): PAM, Wallet/Ledger, Bonus Engine, Cashier/PSP Orchestration, Game Sessions, Risk/Anti-Fraud, RG, Jackpot/Tournaments, Affiliates, CRM/Notifications, Compliance/Reporting.

3. Daten-/Integrationsschicht: Ereignisbus (Kafka/Pulsar), Warteschlangen (SQS/Rabbit), CDC/Outbox, ETL/ELT (im BI-Showcase), Feature Store/ML, Caches (Redis), DB OLTP (Postgres/Oracle), OLAP (ClickHouse/BigQuery).

4. Observability & SecOps: metrics/tracing/logs, SIEM/SOAR, secrets (Vault/HSM), keys and tokens, RBAC/ABAC, audit log (WORM).

2) Domänenmodule (minimal erforderliche Zusammensetzung)

2. 1 PAM (Player Account Management)

Registrierung/Login, SSO, Sitzungs- und Geräteverwaltung, KBA/2FA.

Profil: Alter/Geo/Währung/Segmente, RG-Status/Selbstausschlüsse.

Einschränkungen: Zugang zu Spielen nach Gerichtsbarkeit, Bans, "Reality-Checks'.

2. 2 Wallet/Ledger (Geldkreislauf)

Multiwährungskonten, Doppelerfassung (Debit/Credit), unveränderliche Buchungen.

Atomare Wett- und Gewinntransaktionen (idempotency keys, exactly-once innerhalb einer Domain).

Holds für aktive Rücken/Runden; Jackpot-Transitkonten.

Interaktion nur über Befehle (command API), Lesen über Projektionen (CQRS).

2. 3 Cashier / PSP Orchestration

Routing von Zahlungen nach Geo/Bin-Bereich/Scoring; Kaskadierung bei Ausfällen.

3-DS/AVS/velocity-Regeln; Tokenisierung von Karten; on-/off-ramp für Krypto.

SLO-Set: Autorisierung ≤ 3c p95, Gesamterfolg der Einzahlung ≥ 85% auf Geo.

2. 4 Game Sessions (Integration mit Anbietern)

Erstellung von Spielsitzungen (Token Handshake), Validierung des Landes/der Währung/des Alters.

Die Ereignisse laufen stavka→iskhod→settlment auf dem Bus; RNG und Abrechnung liegen auf der Anbieterseite.

Anti-Missbrauch: min Wette, die Häufigkeit der Spins, das Verbot der Änderung der Bezeichnung „innerhalb des Trikes“.

2. 5 Bonus Engine

Bonus-States (issued/locked/active/forfeit), Weiterleitung, Spielbeitrag, max bet/max cashout, Deadlines.

Missionen/Quests, Freispiele, Cashback; Kompatibilität mit Turnieren/Jackpots.

Strenge Gültigkeit der Regeln zum Zeitpunkt der Wette; Eine unveränderliche Geschichte.

2. 6 Risk / Anti-Fraud

Verhaltenssignale (Wettgeschwindigkeit, Multi-Accounts, geteilte Geräte/Karten).

Velocity-Regeln, Graph-Überprüfung von Links, Chargeback-Verteidigung.

Reaktionen: mild (Grenzen), hart (Block/Eskalation in AML).

2. 7 Responsible Gambling (RG)

Einzahlungs-/Verlust-/Wett-/Zeitlimits, Timeouts, Selbstausschluss.

„Realitätschecks“ und Zwangspausen; Speicherung von Einwilligungen und Protokollen.

2. 8 Jackpots & Tournaments

Lokal/Netzwerk, fix/progressiv; Teilnahmegebühr mit jedem Einsatz.

Öffentliche Führungsgremien; unabhängige Überprüfung der Ergebnisse; Anti-Bot.

2. 9 Affiliates & CRM

Sub-ID-Tracking, Attribution (CPA/RevShare/Hybrid), Post-Backs.

Segmentierung, Trigger, Suppressionsregeln, Omnichannel (Push/E-Mail/SMS).

2. 10 Compliance & Reporting

Regulatorische Entladungen, Steuerberichte, SAR/STR; audit-log WORM.

Datenresidenz nach Gerichtsbarkeit (EU/UK/BR usw.).

3) Ereignismodell und Datenbusse

3. 1 Basis-Topics (Beispiel Kafka-Namensgebung)

`player. registered`, `player. kyc. status. changed`

`wallet. debit. requested/committed/failed`, `wallet. credit.`
`game. session. started/ended`, `bet. placed`, `bet. settled`
`bonus. issued/consumed/forfeited`, `wager. progress. updated`
`rg. limit. hit`, `rg. timeout. started/ended`
`cashier. deposit. requested/succeeded/failed`, `withdrawal. requested/sent`
`risk. alert. raised/closed`, `aml. case. opened`
`jackpot. contribution/triggered`, `tournament. score. updated`

Verträge: Avro/JSON Schema + Schema Registry, versioning (backward compatible), strikte idempotence keys.

3. 2 Ereignisvorlage (vereinfacht)

json
{
"event_id": "uuid",  "event_type": "bet. settled",  "occurred_at": "2025-10-23T16:09:12Z",  "tenant_id": "brand-1",  "player_id": "p_123",  "session_id": "s_456",  "trace_id": "t_abc",  "payload": {
"game_id": "provider:slot_777",   "bet_amount": {"amount": 2. 00, "currency": "EUR"},   "win_amount": {"amount": 36. 40, "currency": "EUR"},   "bonus_impacted": true
}
}

Regel: Ereignisse - unveränderlich; Anpassungen durch einzelne kompensierende Ereignisse.

3. 3 Outbox & CDC

Alle Domain-Transaktionen schreiben das Ereignis in die Outbox in der gleichen DB → der Hintergrund-Pablish sendet an den Bus.

CDC (Debezium und Analoga) - für Sekundärströme in DWH ohne OLTP-Belastung.

4) Konsistenz, Saga und Idempotenz

Sagas für lange Prozesse (Einzahlung/Cashout, Verifizierung, Turnierbelohnungen).

Idempotenz aller Befehle: 'Idempotency-Key' + Service-seitige Deduplizierung.

Konsistenzstrategie: im Geldbeutel - streng (ACID), ansonsten - eventual (durch Projektionen).

Entschädigungen: einzelne Domain-Events, Verbot von „manuellen Bearbeitungen“ im Ledger.

5) Daten: OLTP/OLAP, Caches, Projektionen

OLTP: Postgres/Oracle für Wallet, PAM, Boni (p95 <150 ms).

Caches: Redis für Sessions, Limits, heiße Leaderboard-Projektionen.

OLAP: ClickHouse/BigQuery — витрины KPI (FTD, NGR, ARPPU, Retention, LTV, Wager progress, Risk flags).

Projektionen (CQRS): schnelle Suche nach Spielern/Transaktionen (<2c), Echtzeit-RG-Panel/Risiko.

6) Zahlungs-Orchestrierung: ausführlicher

Routing-Regeln: Geo, BIN, Risiko, Last, Kosten.

Kaskade: PSP1 → PSP2 ohne Korbverlust Retrays mit exponentieller Pause.

Überleitungen: tägliche PSP-Berichte → Wallet-Register; Auto-Diskrepanzen → Tickets.

7) Integrationen mit Spieleanbietern

Gateway-Muster: ein einziges Spiel API, Mapping Währungen/Zahlen, Gesundheitscheck mit Degradierung.

Settlement: Eingehende Providerkollektion → Wallet-Domain-Team. settle mit idempotence Schlüssel.

Blockaden: minimal; Wette/Gewinn ist ein atomares Paar von Transaktionen.

8) Beobachtbarkeit und SLO

Метрики: p95/p99 latency per service, error rate, saturation, business KPIs (bets/min, settle lag, deposit success).

Tracing: trace_id durch (edge→domeny→shina→konsyumery).

Protokolle: strukturiert, mit PII-Bearbeitung.

SLO-Minimum:

Kernel ≥ 99,95%
Wallet p95 <150 ms
Verlorene/duplizierte Settlemente = 0
Ereignisverzögerungszeit bis BI <5 min

9) Sicherheit und Compliance

Zero-Trust: mTLS in Mesh, kurzlebige Token, RBAC/ABAC, das Prinzip der geringsten Rechte.

Geheimnisse: Vault/HSM, Schlüsselrotation, KMS-Datenverschlüsselung „at rest“.

PCI DSS/GDPR/lokale Gegenstücke: Segmentierung von Umgebungen, PAN-Tokenisierung, DLP, Access Log (WORM).

WAF/Bot-Schutz: Filter für Verhaltenssignale, Device-Fingerprinting.

Datenresidenz: Sharding nach Regionen; Verbot regionenübergreifender PII.

10) Verfügbarkeit, DR und Release-Version

Aktiva-Aktiva/Aktiva-Passiva nach Regionen; RPO ≤ 5 min, RTO ≤ 30 min.

Kanarische Releases/Feature-Flags, Rollbacks; DB-Migrationen - über ghost/sekundäre Indizes.

Chaos-Engineering: regelmäßige Fails von Netzwerken/PSPs/Providern zur Überprüfung der Degradation.

11) Schema- und Datenqualitätsmanagement

Datenverträge: Versionierung von Ereignissen (Semver), vertragliche Tests von Produzenten/Konsumenten.

Hoverance: Datenkatalog, Vertrauen in Quellen, SLA-Schaufensteraktualisierungen.

Qualität: Deduplizierung, späte Ankunft, idempotent Upserts in OLAP.

12) Rollen und Zugriffe (Back-Office)

RBAC: klare Rollen (Finanzen, Risiko, Saport, Marketing, Compliance).

Kreta-Aktionen: 4-Augen-Bestätigungen, ein Protokoll unveränderlicher Operationen.

PII-Bildschirm: Maskierung; Vollzugriff - auf Anfrage/temporäre Token.

13) Casino Core Reifegradmetriken (Selbsteinschätzung)

1. Zuverlässigkeit: Wallet/Cash/Session SLOs werden ≥ 99% der Tage durchgeführt.

2. Daten: Ereignisse fallen ≤ 5 Minuten in BI; Die Konsistenz von Ledgers vs PSP ≥ 99,99%.

3. Boni: Regelersteller ohne DB-Änderungen; Prüfung von Änderungen.

4. RG/AML: Echtzeitsignale; Berichte/Uploads werden automatisiert.

5. Vorfälle: MTTR <30 min; Postmortems sind intern öffentlich.

6. Tests: Vertrag, Belastung, Chaos-Tests; Testsandboxen der Anbieter/PSP.

14) Checkliste Architekturprüfer

Es gibt outbox/CDC, das Ereignis wird atomar mit der Transaktion veröffentlicht.
Der Ledger ist als unveränderliches Buchungsbuch implementiert; Es gibt einen Abgleich mit der PSP.
Alle Befehle sind idempotent; Deduplizierung von Schlüsseln.
Getrennt nach OLTP und OLAP; Projektionen schlagen nicht auf den Kampf DB.
RG-Limits gelten synchron zum Einsatz; reality-check ist erzwungen.
Game Gateway wird bei Vorfällen zu Read-only/“ no new sessions“ degradiert.
der DR-Plan wird regelmäßig durchgeführt; Backups werden durch Recovery validiert.
Die Politik der Schlüssel/Geheimnisse und deren Rotation ist dokumentiert.
Compliance-Berichte werden automatisch gesammelt (keine Excel-Handarbeit).
Audit-Protokolle - WORM, Zugang nach dem Prinzip der geringsten Rechte.

15) Anti-Muster („rote Fahnen“)

Manuelle Bearbeitungen von Salden und Boni in der DB.

Mischung aus öffentlicher und privater API, kein API-Gateway.

Aufzeichnung von Ereignissen „unter Umgehung“ von Domain-Transaktionen (nicht über Outbox).

Monolithische Geldbörse und Boni ohne Idempotenz und Sagen.

Eine einzige DB „für alles“ + BI-Anfragen nach einem Kampfschema.

Keine Versionierung von Veranstaltungen und Vertragstests.

Es gibt kein Register für Änderungen der Bonusregeln und Turnierformeln.

Zahlungsausfälle ohne Kaskade; „Später ausprobieren“ als Strategie.

Keine RG-Werkzeuge „out of the box“; Lizenz auf Vertrauen.

Casino Core ist ein Event-basiertes, streng limitiertes „Netzwerk“ von Dienstleistungen, bei dem Geld und Verantwortung an erster Stelle stehen. Eine starke Architektur ruht auf drei Säulen:

1. Harte Integrität des Geldes (Ledger, Idempotenz, Sagas, Outbox/CDC), 2. Event und Beobachtbarkeit (Verträge, Tracing, SLO, BI-Showcases), 3. Standardsicherheit und Compliance (Zero-Trust, PCI/GDPR, RG/AML).

Durch den Aufbau dieser Grundlagen skaliert der Betreiber Inhalte, Bonusökonomie und Marketing ohne Risiko für die Hauptsache - das Geld der Spieler und den Ruf der Marke.