Cum funcționează API-ul jackpot-ului

Articol complet

💡 18+. Materialul este aplicat-inginerie, fără un apel pentru a juca. Termeni: platformă - PAM/portofel/casierie/bonusuri/RG; RGS - Server de jocuri de la distanță (nucleul jocurilor de studio); agregator - strat unificat pentru mai multe RGS; JP - serviciu de jackpot.

1) Ce este un sistem de jackpot și unde se află în ecosistem

Sistemul jackpot este un serviciu separat (uneori un grup de servicii) care colectează contribuții din pariuri, gestionează piscine și declanșatoare de câștig, calculează distribuția premiilor și inițiază plăți prin bucla de plată a operatorului. Se integrează:

cu RGS (mesaje despre rate/rezultate și calificări), cu o platformă/portofel (eliminarea contribuțiilor și creditarea câștigurilor), cu un agregator (rutare de la multe studiouri/mărci), cu un BI/regulator (telemetrie și raportare).

2) Tipuri de jackpot-uri (și ce se schimbă în API)

1. Fix-Suma premiului cunoscut în avans. Nu există piscină în API, doar verificarea condițiilor și creditul.

2. Progresiv: Piscina crește din contribuțiile la pariuri. Avem nevoie de puncte finale ale contribuției și publicarea dimensiunii actuale.

3. Multi-tier (Multi-tier: Mini/Major/Grand): mai multe piscine paralele cu diferite cote și capace.

4. Rețea locală vs: piscină locală - un operator/brand; rețea - total pentru mulți operatori/mărci/regiuni (multi-chirie și replicare sunt critice).

5. Timp/eveniment: o piscină cu un termen limită sau pe un program (cronometre și auto-draw-uri sunt necesare).

3) Invarianți monetari

Sursa adevărului în balanță este portofelul/registrul platformei. JP stochează doar starea piscinelor și a datoriilor.

Toate tranzacțiile bănești sunt idempotente (chei 'jp _ curb _ id',' jp _ trigger _ id', 'jp _ payout _ id').

Câștiguri pierdute/duplicate = 0. Compensare - numai prin evenimente (sagas), nu prin modificări manuale ale bazei de date.

Contribuție separată, declanșare și plată ca tranzacții independente cu propria telemetrie.

4) Contracte de referință API

4. 1 JP RGS/agregator de → (contribuții și declanșatoare)

„POST/v1/jp/contribuții” - contabilizarea contribuției grupului

json
{
" :" uuid-1 "," : "brand-42", " :" grand-eu-01 ","  "" : " ": "" pariu ": {" sumă ": 2. 00, „valută”: „EUR”}, „}”: {„sumă”: 0. 02, „monedă”: „EUR”} „, occurred_at": „2025-10-23T15:12:05Z,” „idempotency_key": „round_r_123”
}

„POST/v1/jp/candidați” - cerere de participare/verificare a condițiilor (opțional)

Răspuns: 'eligibil: adevărat/fals', greutate sau șansă, reguli.

„POST/v1/jp/triggers” - înregistrarea faptului operațiunii

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

💡 Notă: în unele modele, declanșatorul este inițiat chiar de JP (ruletă internă), iar RGS raportează doar runda. Apoi, „triggers” sunt numite JP→platforma și RGS abonează la eveniment.

4. 2 Platforma → JP (plăți/provizioane)

„POST/v1/portofel/rezervă” - (opțional) prevedere pentru plata viitoare

'POST/v1/portofel/credit' - câștigă creditul jucătorului

json
{
„ : „uuid-3”, „ : „brand-42”, „ „:”  „: „grand-eu-01”, „sumă”: {„sumă”: 500000. 00, „valută”: „EUR”}, „meta”: {„taxă”: „reținut = fals',” nivel „:” grand „},” idempotency_key": „jp_p_grand_r_123”
}

Răspunsurile platformei: "credit. ok	eșuat ", cu coduri de motive (RG/AML, limite de retragere, sancțiuni, geo-bloc).

4. 3 Publicați starea piscinei (pentru fronturi/widget-uri)

'GET/v1/jp/pools/{ pool _ id}' → dimensiunea curentă, sămânța, capacul, numărul de participanți, ETA etc.

"GET/v1/jp/pools' → lista de piscine după marcă/regiune cu filtre.

5) Modelul evenimentului (Kafka/Pulsar) și diagrame

Subiecte de bază:

'jp. contribuție. recorded '
'jp. piscină. actualizat "(dimensiune, actualizări competitive)
'jp. "

'jp. plata. solicitat	creditate	a eşuat "
"umed. credit. "(oglindire pentru saga)
"rg. limită. hit ',' aml. alertă. deschis "(în cazul în care plata este blocată)
Audit. config. modificat "(limite, semințe, capac, distribuție)

Contracte: Avro/JSON Schema + Schema Registry, chei de participare 'chiriaș _ id',' pool _ id', 'player _ id'. Versioning - compatibil înapoi.

6) Algoritmi de declanșare (nivel înalt)

Probabilistic (p-stabil): pentru fiecare rundă calificată generăm un hit cu probabilitatea 'p' (în funcție de tipul de piscină/nivel).

Intervalul (must-drop): piscina trebuie să se încadreze în suma-capac sau termenul limită - păstrați aleatoriu intern în intervalul [min, max], publicați capacul/ETA.

Managementul semințelor și entropiei: semințe de server + sare rotundă; abandonarea de locuri jackpot client. Toate modificările la semințe sunt sub audit WORM.

Onestitate: declanșatorul nu ar trebui să depindă de personalitatea specifică a jucătorului (altele decât regulile de geo/licență/calificare). Orice direcţionare „personală” este tabu.

7) SLO și performanță

p95 'contribuţie' <120 ms, p99 <250 ms.

p95 'trigger→credit' <500 ms (fără hamei de plată extern).

„Plăți pierdute/duplicate” = 0 (verificate prin teste contractuale).

Livrare eveniment la BI ≤ 5 min.

Disponibilitatea API JP pentru căi critice ≥ 99. 95%.

8) Siguranță și conformitate

mTLS + semnături (HMAC/EdDSA) pe toate apelurile S2S jetoane cu durată scurtă de viață.

Zero-trust: politici de rețea/rețea, privilegii minime, segmentare pe regiuni.

Auditul WORM al modificărilor la limite, formule, semințe/entropie, configurații ale piscinei.

GDPR/Data residency/PCI: PII și busteni - în regiune; tokenizarea domeniilor sensibile; interzicerea citirilor transregionale.

RG/AML: lumini de frână sincrone pe plată; Încărcările SAR/STR sunt automatizate.

9) Coerență și saga

Contribuție ("contribuție") - fixați în JP, publicați "jp. contribuție. înregistrat ".

Trigger („declanșat”) - creează o obligație; JP lansează 'payout' saga.

Plată ("plată. →-a cerut portofelul. credit. ok ') - se termină saga; cu fals - retrai cu deduplicare.

Outbox/CDC este singura modalitate de a publica evenimente; fără "by-pass'.

10) Telemetrie și tablouri de bord

Afaceri:

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

Tehnic:

p50/p95/p99 по „contribuție”, „declanșator”, „plată”;
rata de eroare с типами (5xx/4xx/business), încercați din nou furtuni, coadă lag;
"umed. latența creditului/ok-rate; conflict actualizare piscină.

Alerte:

growth 'payout. eșuat "> X% după marcă/regiune," pool _ size "> cap - Y% din timp (eroare de configurare), derivă între" pool _ size "și suma contribuției de reconciliere> Z ppm.

11) Multi-chirie și izolare

Toate cererile și evenimentele sunt marcate 'chiriaș _ id/brand _ id/license/region'.

Bazinele locale/de rețea sunt separate fizic (DB/cluster) sub diferite licențe/regiuni.

Securitatea la nivel de rând (RLS) și mascarea în vitrinele BI.

Chei individuale/secrete și spații schematice pe marcă/regiune.

12) Integrarea cu bonusuri/turnee

Contribuțiile nu cresc vagerul direct; contribuția la bonus - vine din pariu, nu din contribuție.

Turneele pot acorda puncte pentru "participare JP" sau "contribuție de top. „Sursa - evenimente” jp. contribuție. înregistrat „и” jp. declanșat ".

Regula obligatorie: Mecanica jackpot-ului nu schimbă RTP-ul de bază al jocului; în caz contrar, este necesară certificarea separată.

13) Testarea și practicile haosului

Teste contract RGS↔JP↔koshelyok: dublu-livrare, întârzieri, out-of-order, rollback.

Teste de încărcare: furtună de pariuri și declanșatoare, scalarea lucrătorilor din piscină.

Exerciții de haos: căderea regiunii JP, portofelul offline, desincronizarea timpului; verificați outbox și degradare (declanșatoare de pauză/fără contribuții noi).

14) Liste de verificare

Pentru Studio/RGS

Idempotent 'contribution' și corect 'round _ id'/' bet _ id'.
Nicio publicație nu „ocolește” tranzacțiile (doar outbox/CDC).
Teste de duplicate/declanșatoare repetate/compensații.
limitele max pariu/calificare sunt transferate la JP.

Pentru operator/platformă

Registrul este sursa adevărului, "portofel. credit "cu eliminare a duplicatelor.
Opririle RG/AML sunt procesate la plată; Rapoarte SAR/STR.
tablouri de bord p95 'trigger→credit', rata de eroare, reconcilieri piscină.

Pentru proprietarul JP

Auditul WORM al modificărilor de formulă/semințe/limită.
Scheme de evenimente în Registru și versioning.
DR: RPO ≤ 5 min, RTO ≤ 30 min; exerciții regulate.
RLS/izolare prin brand/licență; chei/secrete pe regiune.

15) Steaguri roșii (anti-modele)

Modificări manuale ale dimensiunilor piscinei și plăților în baza de date.

Lipsa idempotenței → împrumuturi duplicate.

Publicarea telemetriei fără outbox/CDC → contribuții/declanșatoare „pierdute”.

Amestecarea datelor PII și monetare din diferite regiuni.

Jackpot care afectează RTP-ul jocului de bază fără certificare nouă.

Nu există reconcilieri portofel și piscină; rapoartele se bazează pe OLTP de luptă.

Jackpot systems API este un contract de evenimente monetare între un studio, platformă și operator. Fundația sa: idempotența și saga, izolarea strictă a banilor, schemele de evenimente clare, securitatea și auditul WORM, observabilitatea și SLO. Pe acest design, fixați/progresiv și scalați în mod previzibil grupurile de rețea, plățile rămân corecte, iar raportarea de reglementare și de afaceri sunt transparente și fiabile.