So funktioniert die Jackpot-System-API

Vollständiger Artikel

💡 18+. Das Material ist Engineering und Anwendung, ohne Aufruf zum Spiel. Begriffe: Plattform - PAM/Wallet/Kasse/Boni/RG; RGS - Remote Game Server (der Kern der Spiele des Studios); Aggregator - eine einheitliche Schicht für eine Vielzahl von RGS; JP ist ein Jackpot-Service.

1) Was ist das Jackpot-System und wo steht es im Ökosystem?

Ein Jackpot-System ist ein separater Dienst (manchmal ein Cluster von Diensten), der Beiträge von Wetten sammelt, Pools und Gewinnauslöser verwaltet, die Verteilung von Preisen berechnet und Auszahlungen über die Zahlungsschleife des Betreibers einleitet. Es integriert:

mit RGS (Wett-/Ergebnis- und Qualifikationsmeldungen), mit Plattform/Wallet (Abbuchung von Beiträgen und Gutschrift von Gewinnen), mit Aggregator (Routing von vielen Studios/Marken), mit BI/Regulator (Telemetrie und Reporting).

2) Arten von Jackpots (und was sich in der API ändert)

1. Fest (Fixed): Eine vorab bekannte Gewinnsumme. Es gibt keinen Pool in der API, nur die Überprüfung der Bedingungen und die Gutschrift.

2. Progressiv (Progressive): Der Pool wächst aus den Raten. Wir brauchen Beitragsendpunkte und die Veröffentlichung der aktuellen Größe.

3. Mehrstufig (Multi-Tier: Mini/Major/Grand): mehrere parallele Pools mit unterschiedlichen Quoten und Caps.

4. Lokal vs Netzwerk: lokaler Pool - bei einem Betreiber/einer Marke; Netzwerk - Summe über eine Vielzahl von Betreibern/Marken/Regionen (Multitenant und Replikation sind kritisch).

5. Temporär/Event: Pool mit Deadline oder Zeitplan (Timer und Auto-Ziehungen erforderlich).

3) Monetäre Invarianten

Die Quelle der Wahrheit über das Gleichgewicht ist die Wallet/Ledger-Plattform. JP speichert nur den Zustand der Pools und Verbindlichkeiten.

Alle Geldtransaktionen sind idempotent (Schlüssel 'jp _ contrib _ id', 'jp _ trigger _ id', 'jp _ payout _ id').

„Verlorene/doppelte Auszahlungen“ = 0. Kompensationen - nur Ereignisse (Sagas), nicht manuelle Bearbeitungen der DB.

Trennen Sie den Beitrag (contribution), den Auslöser (trigger) und die Auszahlung (payout) als eigenständige Transaktionen mit eigener Telemetrie.

4) API-Referenzverträge

4. 1 RGS/Aggregator → JP (Beiträge und Auslöser)

„POST/v1/jp/contributions“ - Verbuchung des Poolbeitrags

json
{
"jp_contrib_id": "uuid-1",  "tenant_id": "brand-42",  "pool_id": "grand-eu-01",  "player_id": "p_abc",  "game_id": "studio:slot_777",  "round_id": "r_123",  "bet": {"amount": 2. 00, "currency": "EUR"},  "contrib": {"amount": 0. 02, "currency": "EUR"},  "occurred_at": "2025-10-23T15:12:05Z",  "idempotency_key": "round_r_123"
}

„POST/v1/jp/candidates“ - Teilnahmeantrag/Prüfung der Bedingungen (fakultativ)

Antwort: 'eligible: true/false', Gewicht oder Chance, Regeln.

„POST/v1/jp/triggers“ - Festlegung der Tatsache der Auslösung

json
{
"jp_trigger_id": "uuid-2",  "pool_id": "grand-eu-01",  "reason": "random_hit",  "selector": {"player_id": "p_abc", "round_id": "r_123"},  "occurred_at": "2025-10-23T15:12:06Z",  "idempotency_key": "jp_t_grand_r_123"
}

💡 Hinweis: Bei einigen Modellen ist JP (internes Roulette) selbst der Auslöser und RGS meldet nur die Runde. Dann werden die' Trigger 'JP→platforma aufgerufen und die RGS abonniert das Ereignis.

4. 2 JP → Plattform (Auszahlungen/Reserven)

„POST/v1/wallet/reserve“ - (fakultativ) Reserve für künftige Zahlungen

„POST/v1/wallet/credit“ - Gewinnguthaben für Spieler

json
{
"jp_payout_id": "uuid-3",  "tenant_id": "brand-42",  "player_id": "p_abc",  "pool_id": "grand-eu-01",  "amount": {"amount": 500000. 00, "currency": "EUR"},  "meta": {"tax": "withheld=false", "tier": "grand"},  "idempotency_key": "jp_p_grand_r_123"
}

Die Antworten der Platfoma: 'credit. ok	fehlgeschlagen', mit Ursachencodes (RG/AML, Auszahlungsgrenzen, Sanktionen, Geoblock).

4. 3 Veröffentlichung des Poolstatus (für Fronten/Widgets)

'GET/v1/jp/pools/{ pool _ id}' → aktuelle Größe, Seed, Cap, Teilnehmerzahl, ETA usw.

'GET/v1/jp/pools' → eine Liste von Pools nach Marke/Region mit Filtern.

5) Ereignismodell (Kafka/Pulsar) und Diagramme

Basistopics:

`jp. contribution. recorded`
`jp. pool. updated'(Größe, wettbewerbsfähige Updates)
`jp. triggered`

`jp. payout. requested	credited	failed`
`wallet. credit.'(Spiegelung für Sagen)
`rg. limit. hit`, `aml. alert. opened'(wenn die Auszahlung blockiert wird)
`audit. config. changed'(Grenzen, Samen, Kappe, Verteilung)

Verträge: Avro/JSON Schema + Schema Registry, Partitionierungsschlüssel 'tenant _ id', 'pool _ id', 'player _ id'. Die Versionierung ist backward-kompatibel.

6) Triggeralgorithmen (auf hoher Ebene)

Probabilistisch (p-stabil): Für jede qualifizierte Runde generieren wir einen Treffer mit der Wahrscheinlichkeit'p'(pool-/typabhängig).

Range (must-drop): Der Pool muss auf eine Cap-Summe oder Deadline fallen - wir halten den internen Random im Bereich [min, max], wir veröffentlichen Cap/ETA.

Sid- und Entropy-Management: Server-Seed + per-Round-Salz; Ablehnung von Kundensitzen für Jackpots. Alle Seed-Änderungen unterliegen einem WORM-Audit.

Ehrlichkeit: Der Auslöser sollte nicht von der spezifischen Persönlichkeit des Spielers abhängen (außer Geo-/Lizenz-/Qualifikationsregeln). Jedes „persönliche“ Targeting ist tabu.

7) SLO und Leistung

p95 'contribution' <120 ms, p99 <250 ms.

p95 'trigger→credit' <500 ms (ohne externe Zahlungs-Hops).

„Verlorene/doppelte Auszahlungen“ = 0 (durch Vertragstests überprüft).

Event-Zustellung in BI ≤ 5 Min.

Verfügbarkeit der JP-API für kritische Pfade ≥ 99. 95%.

8) Sicherheit und Compliance

mTLS + Signaturen (HMAC/EdDSA) auf allen S2S-Anrufen; kurzlebige Token.

Zero-Trust: Netzwerkrichtlinien/Mesh, Mindestprivilegien, Segmentierung nach Regionen.

WORM-Audit von Änderungen von Limits, Formeln, Seed/Entropy, Config Pools.

DSGVO/Datenresidenz/PCI: PII und Protokolle - in der Region; Tokenisierung empfindlicher Felder; Verbot überregionaler Lesungen.

RG/AML: synchrone Bremslichter auf Auszahlung; SAR/STR-Entladungen sind automatisiert.

9) Konsistenz und Sagas

Beitrag ('contribution') - wir fixieren in JP, wir veröffentlichen 'jp. contribution. recorded`.

Trigger ('triggered') - schafft eine Verpflichtung; JP startet die' payout '-Saga.

Auszahlung ('Auszahlung. requested → wallet. credit. ok') - beendet die Saga; bei feile - Retrays mit Deduplizierung.

Outbox/CDC ist der einzige Weg, um Ereignisse zu veröffentlichen; keine „Bypass“ -Logger.

10) Telemetrie und Dashboards

Unternehmen:

`pool_size`, `contrib_rate`, `avg_contrib_per_bet`, `time_to_drop`, `payouts_count/sum`, `tier_distribution`.

Technisch:

p50/p95/p99 по `contribution`, `trigger`, `payout`;
error rate с типами (5xx/4xx/business), retry storms, queue lag;
`wallet. credit` latency/ok-rate; Konflikt bei der Pool-Aktualisierung.

Alerts:

Wachstum 'payout. fehlgeschlagen'> X% nach Marke/Region, 'pool _ size'> cap - Y% der Zeit (Konfigurationsfehler), drift zwischen 'pool _ size' und Höhe der Abstimmungsbeiträge> Z ppm.

11) Multitenant und Isolierung

Alle Anfragen und Veranstaltungen sind mit 'tenant _ id/brand _ id/license/region' gekennzeichnet.

Lokale/Netzwerk-Pools sind physisch (DB/Cluster) unter verschiedenen Lizenzen/Regionen getrennt.

Row-Level-Sicherheit (RLS) und Maskierung in BI-Vitrinen.

Individuelle Schlüssel/Geheimnisse und schematische Räume pro Marke/Region.

12) Integration mit Boni/Turnieren

Die Beiträge erhöhen die Zustellung nicht direkt; Beitrag zum Bonus - kommt vom Einsatz, nicht vom Beitrag.

Turniere können Punkte für „JP-Teilnahme“ oder „Top-Beiträge“ vergeben. Quelle - Ereignisse' jp. contribution. recorded` и `jp. triggered`.

Obligatorische Regel: Jackpot-Mechanik ändert nicht die grundlegende RTP des Spiels; Andernfalls ist eine separate Zertifizierung erforderlich.

13) Test- und Chaos-Praktiken

Vertragstests RGS↔JP↔koshelyok: doppelte Lieferung, Verzögerungen, Out-of-Order, Rollback.

Belastungstests: Sturm der Einsätze und Auslöser, Skalierung der Pool-Worker.

Chaos-Übungen: der Fall der JP-Region, Offline-Brieftasche, Nicht-Synchronisation der Zeit; Überprüfung von Outbox und Degradationen (Pause Trigger/keine neuen Beiträge).

14) Checklisten

Für Studio/RGS

Idempotente' contribution 'und korrekte' round _ id '/' bet _ id'.
Keine „Umgehung“ von Transaktionen (nur Outbox/CDC).
Take/repetitive Trigger/Kompensationstests.
Max bet/Qualification Limits werden an JP übergeben.

Für Betreiber/Plattform

Ledger ist die Quelle der Wahrheit, 'wallet. credit 'mit Deduplex.
RG/AML-Stapel werden auf Zahlung verarbeitet; SAR/STR-Berichte.
Dashboards p95 'trigger→credit', Fehlerrate, Abgleich von Pools.

Für den Eigentümer JP

WORM-Audit von Formel-/Seed-/Limitänderungen.
Ereignismuster in Registry und Versioning.
DR: RPO ≤ 5 min, RTO ≤ 30 min; regelmäßige Übungen.
RLS/Isolierung nach Marken/Lizenzen; Schlüssel/Geheimnisse pro Region.

15) Rote Fahnen (Anti-Muster)

Manuelle Änderungen an Poolgrößen und Auszahlungen in der DB.

Mangel an Idempotenz → doppelte Kredite.

Telemetrie-Veröffentlichung ohne Outbox/CDC → „verlorene“ Beiträge/Auslöser.

Mischung aus PII und Gelddaten verschiedener Regionen.

Jackpot, der den RTP des Basisspiels ohne neue Zertifizierung beeinflusst.

Keine Brieftaschen- und Poolpfeifen; Berichte basieren auf Kampf OLTP.

Die Jackpot Systems API ist ein monetärer Veranstaltungsvertrag zwischen einem Studio, einer Plattform und einem Betreiber. Seine Grundlage: Idempotenz und Sagas, rigide Isolation des Geldes, klare Ereignismuster, Sicherheit und WORM-Audit, Beobachtbarkeit und SLO. Bei diesem Design skalieren fix/progressive und Netzwerkpools vorhersehbar, die Auszahlungen bleiben korrekt und die regulatorische und geschäftliche Berichterstattung ist transparent und zuverlässig.