Jak działa API jackpot

Pełny artykuł

💡 18+. Materiał jest zastosowany inżynieryjnie, bez połączenia do gry. Warunki: platforma - PAM/portfel/cash desk/bonuses/RG; RGS - Zdalny serwer gier (rdzeń gier studyjnych); agregator - warstwa ujednolicona dla wielu RGS; JP - serwis jackpot.

1) Co to jest system jackpot i gdzie stoi w ekosystemie

System jackpot to oddzielna usługa (czasami klaster usług), która zbiera składki z zakładów, zarządza pulami i wyzwalaczami wygranej, oblicza rozkład nagród i inicjuje płatności za pośrednictwem pętli płatniczej operatora. Integruje on:

z RGS (komunikaty o stawkach/wynikach i kwalifikacjach), z platformą/portfelem (odpisywanie składek i zasilanie wygranych), z agregatorem (routing z wielu studiów/marek), z BI/regulatorem (telemetria i sprawozdawczość).

2) Rodzaje jackpotów (i jakie zmiany w API)

1. Ustalony-Kwota nagrody znana z góry. W API nie ma puli, tylko sprawdzanie stanu i kredyt.

2. Progresywny: Pula rośnie ze składek na zakład. Potrzebujemy punktów końcowych wkładu i publikacji obecnego rozmiaru.

3. Wielopoziomowe (wielopoziomowe: Mini/Major/Grand): wiele równoległych basenów z różnymi kursami i czapkami.

4. Sieć lokalna vs: pula lokalna - jeden operator/marka; sieć - łącznie dla wielu operatorów/marek/regionów (wielopoziomowość i replikacja mają kluczowe znaczenie).

5. Czas/wydarzenie: pula z terminem lub w harmonogramie (zegary i auto-rysunki są potrzebne).

3) Niezmienne środki pieniężne

Źródłem prawdy na balansie jest portfel/księga platformy. JP przechowuje tylko stan puli i zobowiązań.

Wszystkie transakcje pieniężne są idempotentne (klucze 'jp _ curb _ id',' jp _ trigger _ id', 'jp _ payout _ id').

Utracone/powielone wypłaty = 0. Kompensacja - tylko przez zdarzenia (sagi), a nie przez ręczne edycje bazy danych.

Oddzielny wkład, wyzwalanie i wypłata jako samodzielne transakcje z własną telemetrią.

4) Umowy referencyjne API

4. 1 RGS/→ agregator JP (wkłady i wyzwalacze)

„POST/v1/jp/wkłady” - księgowanie składek na pool

json
{
" :" uuid-1 "," : "marka-42", " :" grand-eu-01 "," : " " " " " :"  "" zakład ": {" kwota ": 2. 00, „waluta”: „EUR”}, „”: {„kwota”: 0. 02, „waluta”: „EUR”} „, occurred_at": „2025-10-23T15:12:05Z,” „idempotency_key": „round_r_123”
}

„POST/v1/jp/candidates” - wniosek o uczestnictwo/weryfikacja warunków (nieobowiązkowo)

Odpowiedź: „kwalifikujące się: true/false”, waga lub przypadek, zasady.

„POST/v1/jp/triggers” - rejestrowanie faktu działania

json
{
" :" uuid-2 "," : "grand-eu-01", "reason": " " "selector": {"player _ id':"  " :"  ", "  "
}

💡 Uwaga: w niektórych modelach wyzwalacz jest inicjowany przez samego JP (ruletkę wewnętrzną), a RGS zgłasza tylko rundę. Następnie 'wyzwalacze' są nazywane JP → platforma i RGS subskrybuje zdarzenie.

4. 2 JP → platforma (płatności/rezerwy)

„POST/v1/portfel/rezerwa” - (nieobowiązkowo) rezerwa na przyszłe wypłaty

„POST/v1/portfel/kredyt” - kredyt wygrywający

json
{
„jp_payout_id": „uuid-3”, „tenant_id": „marka-42”, „player_id": „p_abc,” „pool_id": „grand-eu-01”, „kwota”: {„kwota”: 500000. 00, „waluta”: „EUR”}, „meta”: {„podatek”: „withheld = false”, „tier”: „grand”}, idempotency_key": „jp_p_grand_r_123”
}

Odpowiedzi platformy: "kredyt. ok	nie powiodło się ", z kodami uzasadnienia (RG/AML, limity wycofania, sankcje, blok geograficzny).

4. 3 Publikuj status puli (dla frontów/widżetów)

„GET/v1/jp/pools/{ pool _ id}” → aktualny rozmiar, nasiona, nasiona, liczba uczestników, ETA itp.

„GET/v1/jp/pools” → lista puli według marki/regionu z filtrami.

5) Model wydarzenia (Kafka/Pulsar) i schematy

Podstawowe tematy:

'jp. wkład. nagrane "
'jp. basen. zaktualizowany "(rozmiar, aktualizacje konkurencyjne)
'jp. uruchomiony "

'jp. wypłata. wnioskowany	zaksięgowany	nie powiodło się "
'portfel. kredytu. "(lusterko dla sagów)
'rg. limit. trafienie ',' aml. alarm. otwarte "(jeśli płatność jest zablokowana)
'audit. config. zmieniona "(granice, nasiona, czapka, dystrybucja)

Kontrakty: Avro/JSON Schema + Schema Registry, klucze uczestnictwa 'lokator _ id',' pool _ id', 'player _ id'. Wersioning - kompatybilny wstecz.

6) Algorytmy spustowe (wysoki poziom)

Probabilistyka (p-stabilna): dla każdej kwalifikowanej rundy generujemy trafienie z prawdopodobieństwem 'p' (w zależności od typu puli/poziomu).

Zakres (kropla obowiązkowa): pula musi spaść do sumy lub terminu - utrzymać wewnętrzną losowość w zakresie [min, max], opublikować cap/ETA.

Zarządzanie nasionami i entropią: nasiona serwera + sól okrągła; porzucenie klienckich jackpotów. Wszystkie zmiany w nasionach są poddawane audytowi WORM.

Uczciwość: Wyzwalacz nie powinien zależeć od konkretnej osobowości gracza (poza zasadami geo/licencji/kwalifikacji). Każdy „osobisty” cel jest tabu.

7) SLO i wydajność

p95 „wkład” <120 ms, p99 <250 ms.

p95 'spust → kredyt' <500 ms (bez zewnętrznego chmielu płatniczego).

„Utracone/powielone wypłaty” = 0 (sprawdzone testami kontraktowymi).

Dostawa do BI ≤ 5 min.

Dostępność API JP dla ścieżek krytycznych ≥ 99. 95%.

8) Bezpieczeństwo i zgodność

mTLS + podpisy (HMAC/EdDSA) na wszystkich S2S wywołuje krótkotrwałe żetony.

Zero-trust: polityka/siatka sieciowa, minimalne uprawnienia, segmentacja według regionu.

Audyt WORM zmian limitów, formuł, nasion/entropii, konfiguracji puli.

RODO/Data residence/PCI: PII i logi - w regionie; tokenizacja pól wrażliwych; zakaz odczytów międzyregionalnych.

RG/AML: synchroniczne światła hamulcowe przy wypłacie; Przesyłki SAR/STR są zautomatyzowane.

9) Spójność i sagi

Wkład ("wkład") - ustalenie w JP, publikacja "jp. wkład. zarejestrowane ".

Wyzwalacz („wyzwalany”) - tworzy obowiązek; JP uruchamia 'wypłatę'.

Wypłata ('wypłata. zgłoszony → portfel. kredytu. ok ') - kończy sagę; z fałszywym - retrai z deduplication.

Outbox/CDC jest jedynym sposobem publikowania wydarzeń; żadnych rejestratorów „bypass”.

10) Telemetria i deski rozdzielcze

Biznes:

'pool _ size', 'α _ rate', 'avg _, _ bet', 'time _ to _ drop', 'payouts _ count/sum',' tier _ distribution '.

Techniczne:

p50/p95/p99 - „składka”, „wyzwalacz”, „wypłata”;
szybkość błędów, w tym współczynnik popełnienia błędów (5xx/4xx/business), powtórne burze, kolejka opóźnień;
'portfel. opóźnienie kredytu/stopa ok; konflikt aktualizacji puli.

Wpisy:

wypłata wzrostu gospodarczego. nie powiodło się '> X% według marki/regionu,' pool _ size '> cap - Y% czasu (błąd konfiguracji), dryf pomiędzy' pool _ size'i kwota wkładu uzgodnienia> Z ppm.

11) Wielopoziomowość i izolacja

Wszystkie żądania i zdarzenia są oznaczone jako „najemca _ id/brand _ id/license/region”.

Puli lokalne/sieciowe są fizycznie oddzielone (DB/cluster) na różnych licencjach/regionach.

Zabezpieczenie rzędu (RLS) i maskowanie w sklepach BI.

Poszczególne klucze/sekrety i miejsca schematyczne dla każdej marki/regionu.

12) Integracja z bonusami/turniejami

Wkłady nie zwiększają pochwy bezpośrednio; wkład do premii - pochodzi z zakładu, a nie z wkładu.

Turnieje mogą przyznawać punkty za "udział JP" lub "najwyższy wkład. „Źródło - wydarzenia” jp. wkład. nagrane 'н' jp. uruchomiony '.

Obowiązkowa zasada: Mechanika jackpota nie zmienia podstawowego RTP gry; w przeciwnym razie potrzebna jest odrębna certyfikacja.

13) Praktyki testowania i chaosu

Testy kontraktowe RGS i JP i koshelyok: podwójna dostawa, opóźnienia, brak zamówienia, zwrot.

Testy obciążenia: burza zakładów i wyzwalaczy, skalowanie pracowników basenu.

Ćwiczenia chaosu: upadek regionu JP, portfel offline, desynchronizacja czasu; zaznacz skrzynkę odbiorczą i degradację (wyzwalacze pauzy/brak nowych wkładów).

14) Listy kontrolne

Dla Studio/RGS

Idempotentne 'wkład' i poprawne 'round _ id'/' bet _ id'.
Brak publikacji „omijających” transakcje (tylko outbox/CDC).
Badania duplikatów/powtarzających się wyzwalaczy/kompensacji.
maksymalne limity zakładu/kwalifikacji są przenoszone do JP.

Dla operatora/platformy

Księga jest źródłem prawdy ", portfel. kredyt "z deduplikacją.
Przystanki RG/AML są przetwarzane za wynagrodzeniem; Sprawozdania SAR/STR.
p95 'trigger → credit' deski rozdzielcze, wskaźnik błędu, uzgodnienia puli.

Dla właściciela JP

Audyt WORM wzoru/nasion/zmiany limitów.
Schematy zdarzeń w rejestrze i wersioning.
DR: RPO ≤ 5 min, RTO ≤ 30 min; regularne ćwiczenia.
RLS/izolacja według marki/licencji; klucze/sekrety na region.

15) Czerwone flagi (anty-wzory)

Ręczne edycje wielkości puli i płatności w bazie danych.

Brak idempotencji → duplikat pożyczek.

Publikowanie telemetrii bez sklepu/CDC → „utracone” wkłady/wyzwalacze.

Mieszanie danych PII z danymi pieniężnymi różnych regionów.

Jackpot, który wpływa na RTP gry podstawowej bez nowej certyfikacji.

Brak uzgadniania portfela i puli; raporty są oparte na walce OLTP.

Jackpot Systems API to umowa monetarna między studio, platformą i operatorem. Jego fundament: idempotencja i sagi, ścisła izolacja pieniędzy, jasne programy imprez, kontrola bezpieczeństwa i WORM, obserwowalność i SLO. W tym projekcie, ustalenie/progresywny i sieci puli skali przewidywalnie, płatności pozostają poprawne, a regulacje i sprawozdawczość biznesowa są przejrzyste i wiarygodne.