Wie die Backend-Architektur des Casinos funktioniert

1) Das ganze Bild: Domains und Datenströme

Schlüsseldomänen:

Identity & Accounts - Registrierung, Authentifizierung, Rollen, Geräte, Sitzungen.
Wallet & Ledger - Geldkonten, Bonus-Wallets, Transaktionen, Ledger (nur Append).
Gaming & Bets - Spielsitzungen, Wetten, Runden, Berechnung der Ergebnisse, Integration (RNG/Live/Crash usw.).
Boni & Promotions - Freispiele, Cashback, Gutscheine, Wagering (Wetten), Anti-Missbrauch.
Zahlungen (Cashier) - On-Rump/Off-Rump: Karten, APM, Krypto/Stablecoins, KYC-Bindung.
KYC/AML/KYT & RG - Verifizierung von Identität/Adresse/Einkommen, Transaktionsscreening, Limits und Timeouts.
Risiko & Compliance - Einsatz-/Auszahlungslimits, Sanktionslisten, Geoblocking, Audit.
Katalog & Lobby - Liste der Anbieter, Spiele, Kategorien, Grenzen; A/B-Varianten.
Reporting & BI - P&L, GGR/NGR, Retention, Player Lifecycle, Affiliates.
Observability & Ops - Protokolle, Metriken, Traces, Alerts, Betrugssignale.

Orchestrierung: Eine moderne Plattform wird eventgetrieben aufgebaut: Dienste tauschen Ereignisse über den Bus aus (Kafka/NATS), kritische Operationen werden linearisiert (Wallet/Ledger), seitliche Subsysteme signieren und reagieren asynchron (Boni, BI, Benachrichtigungen).

2) Schichtenmodell

Edge-Ebene: API-Gateway, WAF/Bot-Schutz, Rate Limits, Geo/IP-Filter, Feature-Flags.

Service Layer: eigenständige Microservices nach Domain; synchrone Verträge - nur dort, wo sofortige Konsistenz benötigt wird (z. B. die Belastung der Brieftasche bei der Wette).

Event-Bus: wichtige Geschäftsereignisse ('bet. placed`, `round. settled`, `bonus. issued`, `kyc. verified`, `payout. requested`).

Daten: OLTP (Postgres/MySQL) für Transaktionen; KV/Cache (Redis) für Sitzungen/Limits; einen Objektspeicher (S3) für die Protokolle und den Export; OLAP (ClickHouse/BigQuery) für Analysen.

3) Geldbörse und Ledger: das Herz der Plattform

Grundsätze:

Append-only Ledger: Jede Finanztransaktion ist ein Eintrag mit Typ, Betrag, Währung, Quellenangabe (Wette, Bonus, Einzahlung).
Geld- und Bonusguthaben werden verteilt. Sie können Geld und Boni nicht „mischen“; wird die Politik der Geldquellen verwendet.
Atomarität der debet→kredit: Einsatz = Belastung der Geld- oder Bonustasche + Erstellung von Hold; die Berechnung der Runde entfernt hold und macht Kredit/Belastung auf das Ergebnis.

Beispiel für Transaktionen bei einer Wette:

`LEDGER: HOLD` (−10. 00 EUR, source: cash, ref: betId)
`LEDGER: SETTLE_DEBIT` (−10. 00 EUR) + `LEDGER: PAYOUT` (+36. 00 EUR) - wenn WIN
`LEDGER: HOLD_RELEASE` (+10. 00 EUR) - wenn VOID/PUSH

Anforderungen:

Idempotente Operationen (Schlüssel der Idempotenz durch 'requestId').
Versionierung der Balance (optimistisches Locking) zum Schutz vor Rennen.
Klare Abrechnungswährung und Kursbefestigung bei Umrechnungen.

4) Integrationen mit Spieleanbietern

Wallet-Muster:

Seamless - Balance beim Betreiber; Wette/Abrechnung gehen über unsere Echtzeit-API.
Transfer - Einzahlung in die Spielbank beim Anbieter; mehr Reibung, aber eine geringere Anforderung an die Brieftasche aptame.

Synchrone Pfade (kritisch):

`bet. place' → pre-auth im Portemonnaie (hold) → 'accepted/rejected'.

Asynchrone Pfade:

`round. settle' vom Anbieter (Webhook/WS) → settle im Ledger → Busereignis → Reporting/Boni.

Standardisierung über Bridge: einheitliche Ereignisschemata und Bezeichner 'roundId/betId', Limit- und Side-Bets-Mapping-Tabelle, Fehlernormalisierung.

5) Boni, Wagering und Anti-Missbrauch

Modelle: Einzahlungsboni, Freispiele, Rückerstattungen (Cashback), Missionen, Turniere.

Wagering: Der Wettfortschritt wird separat gespeichert. die Regel „welche Einsätze zählen“ (Prozentsätze nach Spielkategorien).

Die Reihenfolge der Abschreibung: erst Bonusgelder, dann echte - oder umgekehrt, streng nach der Politik.

Die Anti-Muster des Spielers: Wetten auf gegenteilige Ergebnisse, Mindesteinsätze für Pharma-Fortschritt, Übertragung zwischen Spielen mit unterschiedlichen Gewichten - gefangen durch Regeln und Scoring.

6) KYC/AML/KYT и Responsible Gaming (RG)

KYC: ID/Adresse/Alter Verifizierung; Status steuern die Limits (deposit/withdraw/betMax).

AML/KYT: Screening von Zahlungskanälen und On-Chain-Adressen (für Krypto), Sanktionslisten, Geldquellen.

RG: Tages-/Wochenlimits, Timeouts, Selbstausschluss; Blockprüfungen werden vor 'bet durchgeführt. place` и `payout. request`.

7) Kasse: Einlagen und Auszahlungen

Einlagen: Kartenanbieter/AWS, Krypto/Stables, lokale Methoden; Webhook-Bestätigungen; Schutz vor Charjback-Risiken.

Auszahlungen: Warteschlangen, Limits, 4-Augen-Prinzip für große Beträge; Geldquellen → „nur Cash-Balance“.

On-Rump/Off-Rump-Krypto: Auto-Konvertierung, KYT-Adressen, Exposure Hedging.

8) Grenzwerte, Risiko und regionale Regelungen

Limitprofile ('DEFAULT', 'VIP _ A', 'VIP _ B', 'ULTRA') nach Land/Währung/CUS.

Geoblocking über IP/GPS/Dokument.

Überschneidungen nach Spielen/Kategorien, Anbieterverbote in Gerichtsbarkeiten.

Reaktion auf Anomalien: Wettspitzen, Korrelation von Geräten/Zahlungen, viele "VOIDs' von einem Benutzer.

9) Beobachtbarkeit und Betrieb

Die Metriken sind: Wallet-Verzögerungen, Gebotsausfall, Rundenzählungszeit, depozita→stavka-Conversion, GGR/NGR, SLA-Auszahlung, Anteil an Bonuswetten.

Protokolle und Traces: Korrelation 'traceId' in allen Ereignissen; Lagerung von Rohereignissen in einem „kalten“ Speicher.

Alertas: Verschlechterung der Wallet-Antwort, Anstieg der 'VOID', Reconcile-Fehler der Berichte, Anstieg der 'RG _ BLOCKED'.

Runbooks: klare Incident-Routinen (Provider-Drop, Ledger-Rassynron, Abbruch von Runden).

10) Sicherheit und Privatsphäre

Auth: short-lived JWT/opaque tokens, Schlüsselrotation ('kid'), mTLS zu kritischen Integrationen.

Zugriffsrichtlinien: strikte Trennung der Rollen (Operations, Finance, Sapport), 2FA; für große Zahlungen - okay von der zweiten Person.

Datenschutz: PII-Verschlüsselung, Tokenisierung von Zahlungsdaten, Speicherminimierung; DSGVO/Löschung auf Anfrage.

Audit: unveränderliche Protokolle, Signatur kritischer Ereignisse, Export für die Regulierungsbehörde.

11) Skalierung und Fehlertoleranz

Steitles-Dienste hinter dem Auto-Scaler; horizontaler Shard für Hot Tables (Wetten, Ereignisprotokolle).

Ledger - vertikaler Bestand + Replikation zum Lesen/Berichten; „Einfrieren“ von Migrationsprogrammen über Schattentabellen.

Caching: Redis mit TTL und „Dual-Check“ -Strategien (Read-Through + Invalidate durch Events).

DR/HA: Multi-AZ, Backups mit regelmäßiger Wiederherstellung, RPO/RTO auf regulatorischer Anforderungsebene.

Degradation Modi: Offline-Kasse, Deaktivieren der „schweren“ Boni, Übertragen von Live-Spielen in die Wartung, wenn der Reifen nicht verfügbar ist.

12) Verträge und Beispiele

Einsatz (Sync, JSON/REST oder gRPC):

json
POST /bets/place
{
"requestId": "9a7f-…",  "playerId": "p_123",  "wallet": "cash",
"roundId": "R-2025-10-17-19:20:05-PRAGM-Table12",  "gameId": "pragm_live_roulette",  "selection": [{"market":"straight","value":"17"}],  "stake": {"amount":"10. 00","currency":"EUR"},  "device": {"ip":"203. 0. 113. 5","ua":"Mozilla/..."}
}

Die Antwort lautet:

json
{
"status": "ACCEPTED",  "betId": "bet_8cd…",  "balanceAfter": "245. 30",  "hold": "10. 00",  "limits": {"maxBet":"5000. 00"}
}

Busereignis (async):

json
{
"event":"round. settled",  "roundId":"R-2025-10-17-19:20:05-PRAGM-Table12",  "bets":[{"betId":"bet_8cd…","outcome":"WIN","stake":"10. 00","payout":"360. 00"}],  "playerId":"p_123",  "ts":"2025-10-17T19:20:09. 231Z",  "traceId":"tr_5f1…"
}

13) Anti-Muster (das bricht die Plattform)

Mischen Sie Bonus und Bargeld in einer einzigen Transaktion ohne Quellen.

Langlebige Token und speichern sie auf dem Client.

Keine Idempotenz bei kritischen Operationen (Debitdoubles).

Monolithisches SQL-Reporting für Combat DB (OLAP vs. OLTP).

Blinde Vollmacht an den Anbieter ohne Reconcile und Limits.

Kein Zeitzonen-Standard (UTC überall!) in Runden-IDs und Berichten.

Synchrone Anrufe in nicht-finanziellen Domains (Boni/Benachrichtigungen) blockieren die Wette.

14) Checkliste Backend Casino starten

Finanzen und Geldbeutel

Ledger append-only, idempotence, version of balance.
Cash/Bonus-Trennung, Quellenpolitik.
Kurse/Konversion werden während der Operation aufgezeichnet.

Integration von Spielen

Einheitlicher Wett-/Abrechnungsvertrag, Format 'roundId/betId'.
Seamless-Wallet standardmäßig; Transfer - nur wo gerechtfertigt.
Automatische VOID/REFUND-Szenarien.

KYC/AML/RG

Richtlinien vor der Zulassung zur Rate/Auszahlung; KYC-Status ↔ Limits.
KYT für On-Chain, Sanktionsscreening, Speicherung der Evidenzbasis.

Kasse

Webhooks/Signaturen, Takes/Retrays, Reconcile mit PSPs/Krypto-Anbietern.
4-Augen für große Zahlungen, Protokoll der Betreiberaktivitäten.

Beobachtungsstand

Wallet-Metriken, Round-Settle-Latenz, Wettausfall, SLA-Auszahlungen.
Traces durch (traceId), Warnungen, runbooks.

Sicherheit

mTLS/HMAC, JWT mit kurzer TTL, Schlüsselrotation.
Rollen/Rechte, 2FA, Tokenisierung von Zahlungsdaten.

Daten

Trennung OLTP/OLAP, CDC in DWH, S3 für Rohereignisse.
Backups und regelmäßige Wiederherstellungstests.

15) Das Ergebnis

Die Backend-Architektur des Casinos ist ein strenger Kern von Geld und Wetten mit linearer Konsistenz und flexibler Peripherie bei Veranstaltungen: Boni, Analysen, Kommunikation. Erfolg wird nicht von der Anzahl der Microservices bestimmt, sondern von der Disziplin: klare Domain-Grenzen, ein Ledger ohne „Magie“, Idempotenz, Beobachtbarkeit und Compliance-Standard. Mit dieser Basis skaliert die Plattform nach Ländern/Währungen/Anbietern und hält Belastungen ohne Kompromisse bei Sicherheit und Geld stand.