Როგორ მუშაობს API ჯეკპოტის სისტემები

სტატიის სრული ტექსტი

1) რა არის ჯეკპოტის სისტემა და სად დგას ის ეკოსისტემაში

ჯეკპოტის სისტემა არის ცალკეული სერვისი (ზოგჯერ მომსახურების მტევანი), რომელიც აგროვებს შენატანებს განაკვეთებიდან, აკონტროლებს მოგების ტყვიებს და გამომწვევებს, ელოდება პრიზების განაწილებას და იწყებს გადახდებს ოპერატორის გადახდის კონტურის საშუალებით. იგი ინტეგრირდება:

• RGS- ით (შეტყობინებები განაკვეთების/შედეგების და კვალიფიკაციის შესახებ), პლატფორმით/საფულესთან (შენატანების ჩამოწერა და მოგების სესხი), აგრეგატორთან (როუტინგი მრავალი სტუდიიდან/ბრენდიდან), BI/რეგულატორთან (ტელემეტრია და ანგარიშგებები).

2) ჯეკპოტის ტიპები (და რა იცვლება API- ში)

1. ფიქსირებული (Fixed): წინასწარ ცნობილი პრიზის ოდენობა. API- ში აუზი არ არის, მხოლოდ პირობების შემოწმება და სესხი.

2. პროგრესული (პროგრესული): აუზი იზრდება განაკვეთების შენატანებისგან. ჩვენ გვჭირდება შენატანის ენდოინტი და მიმდინარე ზომის გამოქვეყნება.

3. მრავალ დონის (Multi-tier: Mini/Major/Grand): რამდენიმე პარალელური ტყვია სხვადასხვა შანსებითა და ქუდებით.

4. ადგილობრივი ქსელის საშუალებით: ადგილობრივი აუზი - ერთი ოპერატორის/ბრენდისთვის; ქსელი - მთლიანი მრავალი ოპერატორის/ბრენდის/რეგიონის მიხედვით (მულტფილმი და რეპლიკაცია კრიტიკულია).

5. დროებითი/ტირიფი: ტყვია ვადაზე ადრე ან გრაფიკით (საჭიროა ტაიმერები და ავტო-მიტინგები).

3) ფულადი ინვარიანტები

ბალანსის სიმართლის წყარო არის საფულე/ledger პლატფორმა. JP ინახავს მხოლოდ ტყვიების მდგომარეობას და ვალდებულებებს.

ყველა ფულადი ოპერაცია იდემპოტურია (გასაღებები 'jp _ contrib _ id', 'jp _ trigger _ id', 'jp _ payout _ id').

„დაკარგული/დუბლირებული გადახდები“ = 0. ანაზღაურება - მხოლოდ მოვლენებით (საგებით), არ არის სახელმძღვანელო შესწორებები BD.

გაზიარეთ საფასური, ტრიგერი და გადახდა (გადახდა), როგორც დამოუკიდებელი გარიგებები საკუთარი ტელემეტრიით.

4) API საცნობარო კონტრაქტები

4. 1 RGS/აგრეგატორი JP (შენატანები და გამომწვევები)

'POST/v1/jp/contributions' - აუზში შეტანილი წვლილის აღრიცხვა

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' - განაცხადი მონაწილეობის/შემოწმების პირობების შესახებ (სურვილისამებრ)

პასუხი: 'eligible: ნამდვილი/false', წონა ან შანსი, წესები.

'POST/v1/jp/triggers' - მუშაობის ფაქტის დაფიქსირება

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

4. 2 JP - პლატფორმა (გადახდები/რეზერვები)

'POST/v1/wallet/reserve' - (სურვილისამებრ) რეზერვი მომავალი გადახდისთვის

'POST/v1/wallet/credit' - მოთამაშისთვის მოგების სესხი

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

4. 3 აუზის სტატუსის გამოქვეყნება (ფრონტებისთვის/ვიჯეტებისთვის)

'GET/v1/jp/pools/{ pool _ id' '- მიმდინარე ზომა, თესლი, კაპი, მონაწილეთა რაოდენობა, ETA და ა.შ.

'GET/v1/jp/pools' არის ბრენდის/რეგიონის ტყვიების სია ფილტრებით.

5) ღონისძიების მოდელი (Kafka/Pulsar) და სქემები

საბაზო ტოპიკები:

• `jp. contribution. recorded`
• `jp. pool. განახლება '(ზომა, კონკურენტული განახლებები)
• `jp. triggered`

კონტრაქტები: Avro/JSON Schema + Schema Registry, 'tenant _ id', 'pool _ id', 'player _ id'. ვერსიაც არის backward compatible.

6) ტრიგერის ალგორითმები (მაღალი დონის)

ალბათობა (p-სტაბილური): თითოეული კვალიფიციური რაუნდისთვის ჩვენ ვქმნით ჰიტს ალბათობით 'p' (დამოკიდებულია აუზზე/დონის ტიპზე).

დიაპაზონი (must-drop): აუზი ვალდებულია დაეცეს cap თანხა ან ვადა - ჩვენ ვატარებთ შიდა random დიაპაზონში [min, max], ვაქვეყნებთ cap/ETA.

Sid- და entropy კონტროლი: სერვერი seed + per-round salt; ჯეკპოტებისთვის კლიენტის ადგილების უარყოფა. ყველა seed ცვლილება - WORM აუდიტის ქვეშ.

პატიოსნება: ტრიგერი არ უნდა იყოს დამოკიდებული მოთამაშის კონკრეტულ პიროვნებაზე (გეო/ლიცენზიის/კვალიფიკაციის წესების გარდა). ნებისმიერი „პირადი“ მიზნობრივი ტაბუ არის ტაბუ.

7) SLO და შესრულება

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

p95 'trigger - credit' <500 ms (გარე გადახდის ჰოპების გარეშე).

„დაკარგული/დუბლირებული გადასახადები“ = 0 (შემოწმებულია ხელშეკრულების ტესტებით).

ღონისძიებების მიწოდება BI-5 წუთში.

JP API- ის ხელმისაწვდომობა კრიტიკულ გზებზე 99. 95%.

8) უსაფრთხოება და შესაბამისობა

mTLS + ხელმოწერები (HMAC/EdDSA) ყველა S2S ზარზე; ხანმოკლე ნიშნები.

Zero-trust: ქსელის პოლიტიკა/mesh, მინიმალური შეღავათები, სეგმენტები რეგიონებისთვის.

WORM აუდიტი limites, formula, seed/entropy, ტყვიის კონფიგურაცია.

GDPR/Data Residence/PCI: PII და ლოგები რეგიონში; მგრძნობიარე ველების ტოქსიკაცია; ჯვარედინი კითხვის აკრძალვა.

RG/AML: სინქრონული გადახდის სიგნალები; SAR/STR გადმოტვირთვის ავტომატიზებულია.

9) კოორდინაცია და საგები

წვლილი ('კონტრიბუცია') - ჩაწერეთ JP- ში, გამოაქვეყნეთ 'jp. contribution. recorded`.

ტრიგერი ('triggered') - ქმნის ვალდებულებას; JP იწყებს საგას 'payout'.

გადახდა ('payout. requested → wallet. credit. კარგი ') - ასრულებს საგას; ყალბი - რესტავრაცია დედუპლიკაციით.

Outbox/CDC მოვლენების გამოქვეყნების ერთადერთი გზაა; არ არის „შემოვლითი“ ლოგერები.

10) ტელემეტრია და დაშბორდი

ბიზნესი:

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

ტექნიკური:

• p50/p95/p99 по `contribution`, `trigger`, `payout`;
• error rate с типами (5xx/4xx/business), retry storms, queue lag;
• `wallet. credit` latency/ok-rate; აუზის განახლების კონფლიქტი.

ალერტა:

• ზრდა failed '> X% ბრენდის/რეგიონის მიხედვით,' pool _ size '> cap - Y% (კონფიგურაციის შეცდომა), drift' pool _ size '- ს შორის და შერჩეული შენატანების ჯამი> Z ppm.

11) მულტფილმი და იზოლაცია

ყველა მოთხოვნა და მოვლენა აღინიშნება 'tenant _ id/brand _ id/license/region'.

ადგილობრივი/ქსელის აუზები ფიზიკურად იყოფა (DB/cluster) სხვადასხვა ლიცენზიით/რეგიონებში.

Row-level უსაფრთხოება (RLS) და შენიღბვა BI ფანჯრებში.

ცალკეული გასაღებები/საიდუმლოებები და სქემატური სივრცეები ბრენდზე/რეგიონში.

12) ინტეგრაცია ბონუსებთან/ტურნირებთან

შენატანები პირდაპირ არ ზრდის ვაგონს; პრემია - მოდის განაკვეთიდან და არა შენატანიდან.

ტურნირებმა შეიძლება დააჯარიმონ ქულები „JP- ში მონაწილეობისთვის“ ან „საუკეთესო დეპოზიტებში მოხვედრისთვის“. წყარო არის მოვლენები 'jp. contribution. recorded` и `jp. triggered`.

სავალდებულო წესი: ჯეკპოტის მექანიკა არ ცვლის საბაზო RTP თამაშს; წინააღმდეგ შემთხვევაში, საჭიროა ცალკე სერტიფიკაცია.

13) ტესტირება და ქაოსის პრაქტიკა

RGS-JP კონტრაქტის ტესტები - საფულე: ორმაგი მიწოდება, შეფერხებები, out-of-order, rollback.

დატვირთვის ტესტები: ფსონების ქარიშხალი და ტრიგერები, აუზის ვორკერების მასშტაბები.

ქაოსის სავარჯიშოები: JP რეგიონის დაცემა, ოფლაინ საფულე, დროის რასინქრონიზაცია; გარე და დეგრადაციის შემოწმება (pause triggers/no new contributions).

14) ჩეკის ფურცლები

სტუდიისთვის/RGS

• Idempotent 'contribution "და სწორი' round _ id '/' bet _ id '.
• არ არსებობს პუბლიკაციები გარიგების გვერდის ავლით (მხოლოდ გარე/CDC).
• დუბლის/განმეორებითი გამომწვევი/კომპენსაციის ტესტები.
• max bet/კვალიფიკაცია გადაეცემა JP- ს.

ოპერატორის/პლატფორმისთვის

• ლედგერი არის ჭეშმარიტების წყარო, 'wallet. credit's ბაბუა.
• RG/AML გაჩერებები დამუშავებულია გადახდაზე; მოხსენებები SAR/STR.
• დაშბორდები p95 'trigger-credit', error rate, ტყვიის კრეკერები.

JP- ს მფლობელისთვის

• WORM აუდიტი ფორმულების/სემის/ლიმიტის ცვლილებების შესახებ.
• მოვლენების სქემები რეგისტრიასა და ვერსიაში.
• DR: RPO - 5 წთ, RTO - 30 წთ; რეგულარული სწავლებები.
• RLS/იზოლაცია ბრენდების/ლიცენზიების მიხედვით; გასაღებები/საიდუმლოებები per region.

15) წითელი დროშები (ანტი-ნიმუშები)

ტყვიების ზომისა და გადახდების სახელმძღვანელო კორექტირება BD- ში.

იდემპოტენტურობის არარსებობა და სესხების დუბლირება.

ტელემეტრიის გამოქვეყნება გარე/CDC გარეშე არის „დაკარგული“ შენატანები/გამომწვევები.

PII ნაზავი და სხვადასხვა რეგიონის ფულადი მონაცემები.

ჯეკპოტი, რომელიც გავლენას ახდენს საბაზო თამაშის RTP- ზე ახალი სერტიფიკაციის გარეშე.

არ არის საფულე და აუზი; მოხსენებები აგებულია საბრძოლო OLTP- ზე.

---

API ჯეკპოტის სისტემები არის ფულადი ღონისძიების ხელშეკრულება სტუდიას, პლატფორმასა და ოპერატორს შორის. მისი საფუძველი: idempotence და საგა, ფულის მკაცრი იზოლაცია, მკაფიო მოვლენების სქემები, უსაფრთხოება და WORM აუდიტი, დაკვირვება და SLO. ამ დიზაინში, ფიქსი/პროგრესული და ქსელის აუზები პროგნოზირებულია, გადახდები რჩება სწორი, ხოლო მარეგულირებელი და ბიზნეს ანგარიშები გამჭვირვალე და საიმედოა.