API cekpot sistemləri necə işləyir

Məqalənin tam mətni

💡 18+. Material - mühəndis-tətbiqi, oyuna çağırış olmadan. Terminlər: platforma - PAM/cüzdan/kassa/bonuslar/RG; RGS - Remote Game Server (studiya oyunlarının nüvəsi); aqreqator - bir çox RGS üçün vahid təbəqə; JP - jackpot xidməti.

1) Jackpot sistemi nədir və ekosistemdə harada dayanır

Cekpot sistemi ayrı bir xidmətdir (bəzən xidmətlər klasteri), o, bahislərdən töhfələr toplayır, uduşların pullarını və triggerlərini idarə edir, mükafatların paylanmasını hesablayır və ödənişləri operatorun ödəniş konturu vasitəsilə başlatır. Bu inteqrasiya olunur:

RGS (bahis/nəticə və kvalifikasiya hesabatları), platforma/pul kisəsi (ödənişlərin silinməsi və uduşların kreditləşdirilməsi), aqreqator (bir çox studiya/brenddən marşrut), BI/tənzimləyici (telemetri və hesabat) ilə.

2) Jackpot növləri (və API-də nə dəyişir)

1. Sabit (Fixed): əvvəlcədən məlum olan mükafat məbləği. API-də heç bir hovuz yoxdur, yalnız şərtlərin yoxlanılması və kredit.

2. Proqressiv (Progressive): Pul bahis töhfələrindən artır. Ödənişin son nöqtələri və cari ölçünün dərc edilməsi lazımdır.

3. Çox səviyyəli (Multi-tier: Mini/Major/Grand): müxtəlif şans və kaplar ilə bir neçə paralel hovuz.

4. Lokal vs şəbəkə: lokal hovuz - bir operator/marka; Şəbəkə - bir çox operator/marka/bölgə üzrə ümumi (multitenantlıq və replikasiya kritikdir).

5. Müvəqqəti/tədbir: vaxtında və ya cədvəli ilə hovuz (zamanlayıcılar və avtomatik tirajlar lazımdır).

3) Pul invariantları

Balans həqiqətinin mənbəyi platformanın pul kisəsi/ledger. JP yalnız hovuzların və öhdəliklərin vəziyyətini saxlayır.

Bütün pul əməliyyatları idempotentdir (açarlar 'jp _ contrib _ id', 'jp _ trigger _ id', 'jp _ payout _ id').

«İtirilmiş/dublyaj ödənişlər» = 0. Kompensasiya - yalnız hadisələr (dastanlar), əl DB düzəlişləri ilə deyil.

Ödənişi (contribution), trigger (trigger) və ödənişi (payout) öz telemetriya ilə müstəqil əməliyyatlar kimi bölüşün.

4) API istinad müqavilələri

4. 1 RGS/aqreqator → JP (ödənişlər və tetikleyicilər)

'POST/v1/jp/contributions' - hovuza töhfənin uçotu

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' - iştirak ərizəsi/şərtlərin yoxlanılması (isteğe bağlı)

Cavab: 'eligible: true/false', çəki və ya şans, qaydalar.

'POST/v1/jp/triggers' - işə düşmə faktının fiksasiyası

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"
}

💡 Qeyd: Bəzi modellərdə tetikləyicinin təşəbbüskarı JP (daxili rulet) və RGS yalnız tur haqqında məlumat verir. Sonra 'triggers' JP → platforma çağırılır və RGS hadisəyə abunə olur.

4. 2 JP → platforma (ödənişlər/ehtiyatlar)

'POST/v1/wallet/reserve' - (isteğe bağlı) gələcək ödəniş üçün ehtiyat

'POST/v1/wallet/credit' - oyunçuya kredit qazanmaq

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"
}

Platfoma cavabları: 'credit. ok	failed ', səbəb kodları ilə (RG/AML, çıxarış limitləri, sanksiyalar, geo-blok).

4. 3 Hovuz statusunun açıqlanması (cəbhələr/widget 'lar üçün)

'GET/v1/jp/pools/{ pool _ id}' → cari ölçüsü, seed, cap, iştirakçı sayı, ETA və s.

'GET/v1/jp/pools' → filtrlərlə marka/region üzrə hovuzların siyahısı.

5) Hadisə modeli (Kafka/Pulsar) və sxemləri

Əsas topiklər:

`jp. contribution. recorded`
`jp. pool. updated '(ölçüsü, rəqabətli yeniləmələr)
`jp. triggered`

`jp. payout. requested	credited	failed`
`wallet. credit. '(saqa üçün güzgü)
`rg. limit. hit`, `aml. alert. opened '(ödəniş bloklanarsa)
`audit. config. changed '(limitlər, seed, cap, paylama)

Müqavilələr: Avro/JSON Schema + Schema Registry, partiyalaşdırma açarları 'tenant _ id', 'pool _ id', 'player _ id'. Version - backward-compatible.

6) Trigger alqoritmləri (yüksək səviyyəli)

Ehtimal (p-stabil): Hər bir ixtisaslı raund üçün 'p' (hovuz/səviyyə tipindən asılı) ehtimalla hit yaradırıq.

Aralıq (must-drop): hovuz cap-məbləğinə və ya müddətinə düşməlidir - daxili randomu [min, max] diapazonunda saxlayırıq, cap/ETA dərc edirik.

Sid- və entropy-nəzarət: server seed + per-round salt; cekpotlar üçün müştəri oturacaqları imtina. Bütün seed dəyişiklikləri - WORM auditi altında.

Dürüstlük: Tetikçi oyunçunun konkret şəxsiyyətindən asılı olmamalıdır (geo/lisenziya/ixtisas qaydaları istisna olmaqla). Hər hansı bir «fərdi» hədəfləmə tabudur.

7) SLO və performans

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

p95 'trigger → credit' <500 ms (xarici ödəniş hopları olmadan).

«İtirilmiş/dubl edilmiş ödənişlər» = 0 (müqavilə testləri ilə yoxlanılır).

Hadisələrin BI-yə çatdırılması ≤ 5 dəq.

Kritik yollar üçün JP API mövcudluğu ≥ 99. 95%.

8) Təhlükəsizlik və uyğunluq

mTLS + bütün S2S çağırışlarında imzalar (HMAC/EdDSA); qısa ömürlü tokenlər.

Zero-trust: şəbəkə siyasətləri/mesh, minimum imtiyazlar, regionlara görə seqmentləşdirmə.

WORM-audit limitləri, düsturları, seed/entropy, hovuz konfiqurasiyaları.

GDPR/Data residency/PCI: PII və log - regionda; həssas sahələrin tokenizasiyası; cross-regional oxunuşların qadağan edilməsi.

RG/AML: ödəmə sinxron stop siqnalları; SAR/STR boşaltma avtomatlaşdırılmışdır.

9) Uyğunluq və dastanlar

Ödəniş ('contribution') - JP-də qeyd edirik, jp-də dərc edirik. contribution. recorded`.

Trigger ('triggered') - öhdəlik yaradır; JP 'payout' dastanını işə salır.

Ödəniş ('payout. requested → wallet. credit. ok ') - dastanı tamamlayır; fale - deduplikasiya ilə retray.

Outbox/CDC hadisələri dərc etməyin yeganə yoludur; heç bir «dolama» loqgerlər.

10) Telemetriya və daşbordlar

Biznes:

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

Texniki:

p50/p95/p99 по `contribution`, `trigger`, `payout`;
error rate с типами (5xx/4xx/business), retry storms, queue lag;
`wallet. credit` latency/ok-rate; hovuz yeniləməsinin konfliktliyi.

Alertlər:

'payout. failed '> X% marka/region üzrə,' pool _ size '> cap - Y% vaxt (konfiqurasiya xətası), drift' pool _ size 'və müqayisə üzrə töhfələrin miqdarı arasında> Z ppm.

11) Multitenantlıq və izolyasiya

Bütün sorğular və hadisələr 'tenant _ id/brand _ id/license/region' ilə qeyd olunur.

Lokal/şəbəkə hovuzları fiziki olaraq (DB/cluster) müxtəlif lisenziyalara/bölgələrə bölünür.

Row-level security (RLS) və BI vitrinlərində maskalanma.

Marka/region üçün ayrı-ayrı açarlar/sirlər və sxematik məkanlar.

12) Bonuslar/turnirlərlə inteqrasiya

Ödənişlər birbaşa veyceri artırmır; bonus töhfəsi - töhfədən deyil, dərəcədən gəlir.

Turnirlər «JP-də iştirak» və ya «top depozitlərə daxil olmaq» üçün xal toplaya bilər. Mənbə 'jp hadisələridir. contribution. recorded` и `jp. triggered`.

Məcburi qayda: Jackpot mexaniki əsas RTP oyun dəyişmir; əks halda ayrıca sertifikatlaşdırma lazımdır.

13) Test və xaos təcrübələri

Müqavilə testləri RGS, JP, cüzdan: ikiqat çatdırılma, gecikmə, out-of-order, rollback.

Yükləmə testləri: fırtına bahisləri və tetikleyicilər, hovuz işçilərinin ölçülməsi.

Xaos təlimləri: JP bölgəsinin düşməsi, oflayn pul kisəsi, zamanın sinxronizasiyası; outbox və deqradasiya yoxlama (pause triggers/no new contributions).

14) Çek vərəqləri

Studiya üçün/RGS

İdempotent 'contribution' və doğru 'round _ id '/' bet _ id'.
Heç bir nəşr «yan keçmək» əməliyyatlar (yalnız outbox/CDC).
Dubl/təkrar trigger/kompensasiya testləri.
Max bet/kvalifikasiya limitləri JP-yə keçir.

Operator/platforma üçün

Ledger həqiqətin mənbəyidir, 'wallet. credit 's baba.
RG/AML-stop ödəmə üzərində emal; SAR/STR hesabatları.
Dashboard p95 'trigger → credit', error rate, hovuz yoxlama.

JP sahibi üçün

WORM-audit düstur/seed/limit dəyişiklikləri.
Registry və versioning hadisə sxemləri.
DR: RPO ≤ 5 dəq, RTO ≤ 30 dəq; müntəzəm təlimlər.
RLS/brendlər/lisenziyalar ilə izolyasiya; açarları/sirləri per region.

15) Qırmızı bayraqlar (anti-nümunələr)

DB-də pulların və ödənişlərin ölçülərinin əl ilə düzəldilməsi.

Qeyri-idempotentlik → iki kredit.

outbox/CDC olmadan telemetriya nəşr → «itirilmiş» töhfələr/tetikleyicilər.

Müxtəlif bölgələrin PII və pul məlumatlarının qarışdırılması.

yeni sertifikatlaşdırma olmadan RTP əsas oyun təsir jackpot.

Heç bir cüzdan və hovuz yoxlama; hesabatlar döyüş OLTP üzrə qurulur.

API cekpot sistemləri studiya, platforma və operator arasında pul-hadisə müqaviləsidir. Onun təməli: idempotentlik və dastanlar, pulun sərt izolyasiyası, hadisələrin dəqiq sxemləri, təhlükəsizlik və WORM auditi, müşahidə və SLO. Bu dizaynda fiks/mütərəqqi və şəbəkə hovuzları proqnozlaşdırıla bilən şəkildə ölçülür, ödənişlər düzgün qalır və tənzimləmə və biznes hesabatları şəffaf və etibarlıdır.