Ცოცხალი თამაშებისა და შოუს ფორმატების ინტეგრაცია RGS/bridge- ის საშუალებით

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

💡 18+. ტექნიკური მასალა ოპერატორების, სტუდიების და აგრეგატორების გუნდებისთვის. არა თამაშის მოწოდება. ტერმინები: პლატფორმა - PAM/საფულე/სალარო/პრემია/RG; RGS - Remote Game Server (სტუდიის თამაშების ბირთვი); bridge არის ინტეგრაციის ფენა პროვაიდერის პირდაპირ ბირთვსა და პლატფორმას/აგრეგატორს შორის.

1) რატომ გვჭირდება bridge პირდაპირ და პლატფორმას შორის

ცოცხალი თამაშები (რულეტი, ბლექჯეკი, ბაკარა) და შოუს ფორმატები (Crazy/Wheel-/Dice-/Game Show) იყენებენ ვიდეოს + რეალურ შედეგს. RNG სლოტებისგან განსხვავებით:

შედეგი მოდის ფსონების ფანჯრის დახურვის შემდეგ და ფიზიკური მოვლენა (უკანა, ბარათის გახსნა).
საჭიროა მკაცრი ვადები (cut-off) და სინქრონული განაკვეთები.
გადახდების გაანგარიშება ხდება ცოცხალი თამაშის ცხრილების მიხედვით, არა სლოტის მატრიცით.
თქვენ უნდა შეთანხმდეთ საფულეზე, პრემიებზე, ტურნირებზე, ჯეკპოტებზე, RG/AML- ზე, ასევე ტელემეტრზე/ანგარიშებზე.

Bridge არის S2S კარიბჭე, რომელიც ცოცხალ მექანიკას „გადასცემს“ პლატფორმის კონტრაქტს: სესიების ნიშნები, საავტორო უფლებები და შეზღუდვები, ფსონების მიღება, ფანჯრის ფიქსაცია, იზოლირება, კომპენსაცია, მოვლენები და დაშლა.

2) ინტეგრაციის ძირითადი არქიტექტურა


Player Client (Web/Mobile + HLS/WebRTC)
│

Live Provider Front (video, UI) —— Live Engine (round control, GCU)
│                │
│ (S2S)            │ emits outcomes

Bridge (RGS/bridge): auth, bet capture, lock, settle, rollback, jackpots/promos
│

Platform: PAM / Wallet(Ledger) / Cashier / Bonus / RG / Risk / BI
│

Aggregator (optional)

როლები:

Live Engine: მართავს რაუნდს, ტაიმერებს, შედეგებს (dealer/GCU).
Bridge: პლატფორმის ერთადერთი ინტეგრაციის წრე. ის სინქრონიზაციას უწევს ფულს და მოვლენებს.
პლატფორმა: სიმართლის წყარო ბალანსის, ბონუსების, RG/AML, ანგარიშების შესახებ.

3) ნაკადები და ტაიმინგი: განაკვეთიდან გადახდამდე

3. 1 რაუნდის სასიცოცხლო ციკლი (გამარტივებული)

1. session. create - ბრენდის/geo/ასაკის შემოწმება, session _ token- ის გაცემა.

2. bet. ადგილი - განაკვეთების მიღების ფანჯარაში; RG ლიმიტების, ბონუსის წესების, Idempotence ('Idempotency-Key') შემოწმება.

3. bet. ჩაკეტვა - ფანჯრის დახურვა (cut-off). ყველა შეუსაბამო განაცხადი უარყოფილია.

4. live. გარეთ - შედეგი Live Engine- დან (რულეტი: ნომერი; შოუ: სექტორი/ფაქტორი/ბონუსის რაუნდი).

5. bet. settle - ატომური ნაკადი: დაადასტურა განაკვეთის დებიუტი, მოგების სესხი (საფულის საშუალებით).

6. bonus/jackpot/tournament - წვლილი/გამომწვევი.

7. rollback/compensation - არხის ჩავარდნის დროს, მაგრამ მხოლოდ რაუნდის წესების შესაბამისად.

3. 2 ფანჯარა და შეფერხებები

Target latence (glass-to-glass): HLS 2-5 სეგმენტიდან; WebRTC 200-500 ms.

SLO bridge:

p95 `bet. place`/`bet. colk '<150 ms (მოთამაშის ქსელის გარეშე), p95' settle '<300 ms "ცოცხალი შემდეგ. outcome ', „დაკარგული/დუბლირებული ნაკრები“ = 0.

4) API bridge კონტრაქტები - პლატფორმა (მაგალითი)

4. 1 მოთხოვნა bridge - პლატფორმა

'POST/wallet/debit' - განაკვეთის დამტკიცება (იდემპოტენტურად, პასუხი - hold _ id).

'POST/wallet/commit' - ჩამოწერის დადასტურება.

'POST/wallet/credit' - მოგების სესხი.

'POST/rg/check' - ანაბრის/ზარალის/დროის ლიმიტები, თვითკმაყოფილება.

'POST/bonus/appy' - წვლილი თამაშის ტიპში (ე. g., live 10–25%).

`POST /jackpot/contribute	trigger '- განაკვეთის/მოგების წილი.
'POST/analytics/event' - ტელემეტრია (round, table, latency, error).

4. 2 კოლბეკი პლატფორმა bridge

`wallet. debit. authorized	rejected`
`wallet. commit. ok	failed`
`wallet. credit. ok	failed`
`rg. blocked` / `rg. limit. hit`
`bonus. state. updated`
`compensation. რეკორდი '(რაუნდის ოქმის მიხედვით)

Idempotence: გასაღებები 'round _ id', 'bet _ id', 'settle _ id'; ბაბუა საფულისა და ბრიჯის მხარეს.

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

ძირითადი ტოპები

`live. session. started	ended`
`live. bet. placed	locked
`live. round. outcome`
`live. bet. settled`
`wallet. debit. requested	committed
`bonus. contributed	awarded`, `jackpot. contribution
`rg. limit. hit`, `rg. reality_check`
`risk. alert. raised`

კონტრაქტები: Avro/JSON Schema + Registry, სემანტიკური ვერსიები, 'tenant _ id', 'table _ id', 'player _ id'.

6) ფულადი ინვარიანტები და საგები

ბალანსის ჭეშმარიტება - ლედგერის პლატფორმა; bridge ინახავს განაკვეთების/რაუნდის მდგომარეობას.

ყველა ფულადი ოპერაცია არის Idempotence, s 'Idempotency-Key'.

Сага «authorize → lock/commit → settle → credit»:

ყალბი 'commit' - ავტორიზაციის/დაბრუნების გაუქმება;
ყალბი 'credit' - წარმატების განმეორება;
ბალანსის სახელმძღვანელო რედაქტირება - აკრძალულია; მხოლოდ ანაზღაურებადი მოვლენები.

7) პრემია, ტურნირები, ჯეკპოტები პირდაპირ ეთერში

Vager- ში შეტანილი წვლილი: ცოცხალი თამაშები ჩვეულებრივ იძლევა წონის 10-25% -ს; bridge ვალდებულია აშკარად გადასცეს მაგიდის/თამაშის ტიპს.

ტურნირები/ფრენები: ბრუნვის ქულები, ფაქტორები, ნაკადები; წყარო - მოვლენები "ცოცხალი. bet. settled`.

ჯეკპოტები: ფიქსი/პროგრესირებადი (ადგილობრივი/ქსელი). წვლილი თითოეული კვალიფიციური კურსით; ტრიგერი - bridge/jecpot სერვისის მხარეს.

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

8) ანტიფროდი და რისკი

Velocity/არბიტრაჟი შეფერხებულია: განაკვეთების აკრძალვა „ფაქტის შემდეგ“; მკაცრი cut-off.

მულტიმედია ანგარიში/ზოგადი მოწყობილობები: გრაფიკული შემოწმება, მოწყობილობის შექმნა.

გამარჯვების ანომალიები: მოსალოდნელი ნიმუშები მაგიდაზე/მოთამაშეზე/რეგიონში.

Chargeback defense: განაკვეთების კავშირი დეპოზიტებთან/მერკანტებთან, logs hold/commit.

9) Observability და ტელემეტრია

ბიზნეს მეტრიკა

`bets_per_round`, `players_on_table`, `avg_bet`, `payout_ratio`, `rake`, `jackpot_latency`, `settle_lag_ms`.

ტექნეტიკა

p50/p95/p99 'bet. place`, `bet. lock`, `settle`, `wallet. debit/commit/credit`;

depth очередей, consumer lag, CPU/mem/GC, TLS errors, WebRTC/HLS QoE (stall ratio).

დაშბორდი

NOC: მაგიდები/შოუები, ონლაინ, bets/min, settle lag, error heatmap რეგიონებში.

SRE: latency per endpoint, queue lag, retrу storms, success of commit/credit.

Alerta (SLO ბიუჯეტი): p95 'settle'> X, error> Y%, lag> Z წამი, კონკრეტული მაგიდის ზრდა 'cancelled'.

WORM აუდიტი: ლიმიტის ცვლილებები, შოუს რაუნდის RTP პროფილები, ჯეკპოტების პარამეტრები, წინსვლის დროშები.

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

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

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

PCI/GDPR/მონაცემთა კვლევა: PII და ლოგოები რეგიონში (EU/UK/BR...), ჯვარედინი კითხვა აკრძალულია.

RG: სინქრონული გაჩერების სიგნალები განაკვეთზე (დეპოზიტების/დანაკარგების/დროის ლიმიტები, თვითგამორკვევა), რეალობის შემოწმება.

აუდიტი: საკრუიზო მოქმედებების ლოგოები უცვლელია (WORM), „ოთხი თვალი“ ხელმისაწვდომია.

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

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

Ledger/Cashier/PII - იზოლირებულია per ლიცენზია/რეგიონი (ხშირად ცალკეული BD/მტევანი).

ზოგადი სერვისები (bridge ბირთვი, ტურნირები, ჯეკპოტები) - shareable, მაგრამ მყარი RLS მონაცემებში.

Fich დროშები/ლიმიტები/ბონუს აუზები - ბრენდის/იურისდიქციის დონეზე.

12) პროდუქტიულობა და დეგრადაცია

Back-pressure: გადატვირთვისას - 'no new bets' cut-off- ის წინ, პრიორიტეტული commit/settle.

Degrade მოდელები: გვერდითი პრომო/ჯეკპოტის გათიშვა, core განაკვეთების შენარჩუნება და გადახდა.

DR გეგმა: აქტივი/აქტივი; RPO - 5 წუთი, RTO - 30 წუთი; გარედან სინქრონიზაცია.

13) განხორციელების სიის სია (ოპერატორი/პროვაიდერი)

არქიტექტურა

ღონისძიების კონტრაქტები (Schema Registry), idempotent- ის გასაღებები 'round _ id/bet _ id/settle _ id'.
Саги authorize→commit→settle→credit; კომპენსაცია ხელის კორექტირების გარეშე.
Outbox/CDC ფულადი სახსრებისთვის; არ არსებობს პუბლიკაციები „გვერდის ავლით“.
Cut-off/lock ხორციელდება ცოცხალი ბირთვის მხარეს და დაცულია ქსელის შეფერხებებით.

ფული/პრემია

ლედგერი, როგორც ჭეშმარიტების წყარო; hold/commit/credit ატომური.

Vager- ში ცოცხალი წვლილი გამჭვირვალეა; ტურნირები/ჯეკპოტები არ ცვლის ძირითადი თამაშის შანსებს.

Observability/SLO

დაშბორდები NOC/SRE; SLO ალერტები latency/error/lag.
WORM აუდიტი ლიმიტებისა და წინა დროშების შესახებ; postmortem პროცესი.

უსაფრთხოება/შესაბამისობა

mTLS + ხელმოწერები; Vault/HSM; RBAC/ABAC; data residency.
RG ფეხები სინქრონულია; AML სიგნალები და მოხსენებები ავტომატიზირებულია.

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

ბალანსების/settlement- ის ხელით რედაქტირება მონაცემთა ბაზაში.

ფსონების მიღება ფანჯრის გასვლის შემდეგ (არ არის მკაცრი ჩაკეტვა).

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

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

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

არ არსებობს დეგრადაცია: პრომო ვარდნა მოგების გაანგარიშებას გამოიწვევს.

BI/მარეგულირებელი მოხსენებები მუშაობს საბრძოლო OLTP- ით.

15) შედეგი

ცოცხალი თამაშებისთვის Bridge არ არის მხოლოდ „API ადაპტერი“, არამედ ფულადი მოვლენის ბირთვი, რომელიც პირდაპირ შედეგს აკავშირებს პლატფორმის მკაცრ ინვარიანტებთან: საფულე, პრემია, RG/AML და ანგარიშები. მისი სიძლიერეა impotence და საგები, მყარი ფანჯრები და კლდეები, დაკვირვება და უსაფრთხოება „ნაგულისხმევი“. ასეთ საძირკველში, live-კაზინოები და შოუს ფორმატები პროგნოზირებულია, გაუძლებს მწვერვალებს და რჩება გამჭვირვალე მოთამაშისთვის, ბრენდისა და რეგულატორისთვის.