REST, gRPC და ვებჰუკები iGaming- ში: ნიმუშები და ნიმუშები

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

💡 18+. ტექნიკური მასალა სასურსათო და საინჟინრო გუნდებისთვის iGaming. არა თამაშის მოწოდება. „პლატფორმა“ გულისხმობს PAM/საფულე/სალარო/პრემია/RG. „პროვაიდერი“ - RGS/live/ჯეკპოტი/აგრეგატორები.

1) ოქმების რუკა: ვინ არის პასუხისმგებელი რაზე

REST - უნივერსალური სინქრონული მოთხოვნები HTTP/JSON. გამჭვირვალე ქეში, მარტივი გამართვა, მოსახერხებელია ინტეგრაციისა და ადმინ-API- სთვის B2B.

GRPC არის მაღალი ხარისხის ორობითი RPC HTTP/2 თავზე: დაბალი ლატენტობა, ნაკადები, მყარი სქემები. კარგია ცხელი ფულადი გზებისთვის (wallet/settle), შიდა სერვისები და გრძელი ნაკადი (ცოცხალი).

ვებჰუკი - საპასუხო ზარები მიმღებიდან გამგზავნამდე. გამოიყენება მოვლენებისთვის („ფული დაეცა“, „ლიმიტი მუშაობდა“), სადაც ინიციატორი ყოველთვის არ არის ის, ვინც შედეგს ელოდება.

ოქროს წესი:

ფული მიდის სინქრონიზებულ RPC (REST/gRPC) მკაცრი ინვარიანტებითა და იდემპოტენტურობით. ტელემეტრია და ბიზნეს მოვლენები - ასინქრონულად (ვებჰუკი + მოვლენების ავტობუსი).

2) ტიპიური ბილიკები და რეკომენდებული არხები

გზა	რეკომენდებულია	რატომ
`bets. authorize` (hold)	GRPC (შიგნით )/REST (B2B)	მინიმალური ლატენტობა, მკაცრი SLA
`bets. settle` → `wallet. credit`	GRPC სინქრონულად + საბურავის მოვლენა	ფული = ACID; მოვლენები = დაკვირვება
`cashier. deposit/withdraw`	REST + idempotence	ინტეგრაცია PSP- სთან, ვაჭრობა
`RG check / stop`	GRPC/REST სინქრონულად	გაჩერების სიგნალები უნდა იმუშაოს მყისიერად
`bonus. issue/consume`	REST სინქრონულად	ბიზნეს ლოგიკა, ზომიერი SLA
`jackpot. trigger/payout`	GRPC/REST + მოვლენა	ფულადი კონტრაქტი + აუდიტი
ტელემეტრია, ანალიტიკა, ალერტა	ვებჰუკი + საბურავი (კაფკა/პულსარი)	სტაბილურობა და მასშტაბები
ცოცხალი სტატუსი/დირექტორია	gRPC streaming / Server-Sent Events	გამოკითხვებისა და ლაგების მინიმიზაცია

3) ორიენტირებული კონტრაქტი

3. 1 REST (ფრაგმენტები)


POST /v1/bets/authorize
Headers: X-Idempotency-Key: bet_r_8c12_1, X-Trace-Id: tr_a1b2
{
"session_id":"s_456",  "bet_id":"b_001",  "round_id":"r_8c12",  "amount":{"amount":2. 00,"currency":"EUR"}
}
→ 200 {"status":"authorized","hold_id":"h_zz1"}

შეცდომები (ერთიანი სქემა):


409
{"code":"DUPLICATE","message":"Bet already authorized","retryable":false,"trace_id":"tr_a1b2"}

3. 2 GRPC (Protobuf, გამარტივებული)

proto syntax = "proto3";
package wallet. v1;

message Money { int64 minor_units = 1; string currency = 2; } // cents message AuthorizeBetReq { string session_id=1; string bet_id=2; string round_id=3; Money amount=4; string idempotency_key=5; }
message AuthorizeBetRes { string status=1; string hold_id=2; }

service Wallet {
rpc AuthorizeBet(AuthorizeBetReq) returns (AuthorizeBetRes);
rpc SettleBet(SettleReq) returns (SettleRes);
}

3. 3 ვებჰუკი (გამოწერის მაგალითი)


POST https://provider. example/webhooks
{
"topic":"wallet. credit. ok",  "callback_url":"https://rgs. example/journal",  "secret":"", "version":"1. 2"
}

ადგილზე მიტანა:


POST https://rgs. example/journal
Headers: X-Signature: sha256=..., X-Trace-Id: tr_a1b2
{
"event_type":"wallet. credit. ok",  "schema_version":"1. 2. 0",  "event_id":"uuid",  "payload":{"player_id":"p_19f3","amount":{"minor_units":1460,"currency":"EUR"}}
}

4) Idempotence და კოორდინაცია

ყოველთვის მოითხოვეთ 'X-Idempotence-Key' write ოპერაციებზე (REST/gRPC metadata). გამეორება - იგივე პასუხი.

საკვანძო შემადგენლობა უკავშირდება ბიზნეს პარამეტრებს (მაგალითად, 'bet _ id + amount').

გრძელი პროცესების საგნები (authorize-commit/colock (settle-credit).

Outbox/CDC: მოვლენები დაფიქსირებულია ატომური გარიგების გვერდით და ქვეყნდება გარედან.

5) ვერსია და თავსებადობა

REST - '/v1/... '+' Deprecation/Sunset '- თავები; gRPC — `package wallet. v1`; მოვლენები - 'schema _ version' სხეულებში + სქემების რეესტრი.

SemVer: minor - ველები optional/ახალი endpoints; მაიორი - ახალი გზა/პაკეტი, მიგრაციის მოვლენების „ორმაგი წერა“.

არასოდეს შეცვალოთ ფულადი სტატუსის სემანტიკა მაიორი ვერსიის გარეშე.

6) ტრანსპორტის უსაფრთხოება

mTLS ყველა S2S- ზე; ვებჰუკებისთვის - სხეულის ხელმოწერა (HMAC/EdDSA) + timestamp და ინტერვალის ფანჯრები.

შეკრების შეზღუდვა (OAuth2 CC) და კლავიშების სეგმენტი per brand/region.

Zero-trust: ქსელის პოლიტიკოსები, მოკლევადიანი ნიშნები, Vault/HSM, კრიტიკული მოქმედებების WORM აუდიტი.

7) დაკვირვება და SLO

'Trace _ id' მეშვეობით REST, gRPC metadata და webhuks.

მეტრიკა: p50/p95/p99 ლატვია, error კოდი კოდებით, throughput, lag რიგები.

SLO მინიმალური (სახელმძღვანელო):

Wallet p95 '<150 ms' (Authorize/Settle), REST საჯარო B2B p95 '<300 ms', Webhuki მიეწოდება '<5 წთ' 99-ე percentil, „დაკარგული/დუბლირებული ნაკრები“ = 0.

8) Retrai, backoff და მიწოდების პროცედურა

REST/gRPC: ექსპონენტური backoff, gitter, ხანგრძლივობის შეზღუდვა (deadline/timeout).

ვებჰუკი: განმეორებითი მიწოდება „2xx“; შეკვეთის შენარჩუნება ღილაკზე ('player _ id/round _ id') ან დუპლიკაცია მიმღებზე.

ანტი-ქარიშხალი: პარალელური რეაგირების ლიმიტი, ცირკულარული ბრეიკერი, საბაზო ლიმიტი.

9) ინტეგრაციის ნიმუშები

პატერნი A: „ფული სინქრონულია, მოვლენები ასინქრონულია“

1. RGS → Wallet (gRPC/REST) `authorize` → `settle/credit`.

2. პარალელურად ქვეყნდება 'bet. settled 'საბურავში, ხოლო პროვაიდერი იღებს ვებჰუკის ქვითარს.

პლუს: სწრაფი ფული, დაკვირვება. მინუს: თქვენ გჭირდებათ ორი წრე.

Pattern B: Streaming Live

Live ბირთვი არის Bridge grRPC Streaming- ის საშუალებით (მაგიდის სტატუსები, განაკვეთების ფანჯარა).

ფულადი ოპერაციები - ცალკეული unary RPC; მოვლენები - საბურავებში/ვებჰუკებში.

პლუს: ცოცხალი სტატუსის მინიმალური შეფერხება.

პატერნი C: „B2B საზოგადოებრივი REST“

კატალოგები/პრემიები/აფილიატები/მოხსენებები - REST, კურდღლის პაგინაციით, ფილტრებით, ETag.

პლუს: პარტნიორების მარტივი ინტეგრაცია.

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

ფულადი ოპერაციები მხოლოდ ვებჰუკების საშუალებით (სინქრონული დადასტურების გარეშე).

Idempotence-Key- ის არარსებობამ დებატების/სესხების დუბლირება მოახდინა.

Outbox/CDC- ის გვერდის ავლით მოვლენების გამოქვეყნება (მოვლენები იკარგება).

ვებჰუკი ხელმოწერის/დროებითი ეტიკეტის გარეშე - ჩანაცვლება.

სხვადასხვა რეგიონის PII/ფულის ნაზავი ერთ არხში 'region/tenant' ჭდეების გარეშე.

დიდი ბინარული პაილოიდი ვებჰუკებში (დარღვევები და შეზღუდვები).

ნულოვანი დეგრადაცია: ვებჰუკების ვარდნა ბლოკავს ფულის გაანგარიშებას.

GRPC deadline გარეშე და backoff- ის გარეშე - შემცირებული ნაერთები, რესურსების ამოწურვა.

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

არქიტექტორი/პლატფორმა

ფული GRPC/REST იდემპოტენტურობით, მოვლენები - ვებჰუკი/საბურავი.
Outbox/CDC ყველა ფულადი გზით.
`/vN` и schema registry; Deprecation/Sunset პროცესი.
mTLS + ვებჰუკების ხელმოწერები; secrects per brand/region.
SLO დაშბორდები p95/p99, error rate, webhook-lag.
DR/xaoc სავარჯიშოები: ორმაგი მიწოდება, out-of-order, დატოვა რეგიონი.

პროვაიდერი/RGS

მე გამოგიგზავნით 'X-Trace-Id' და 'X-Idempotency-Key'.
Retrai ერთად backoff და დედუპლიკაცია; მზად არის ვებჰუკების ხელახლა მიწოდებისთვის.
განაახლეთ ხელშეკრულებების ვერსიები; ვპასუხობ 'დეპრესიას/Sunset- ს ".
ლოგოები/მეტრიკები შეცდომებისა და დროის კოდებით.

12) მინი გადაწყვეტილებები მწვავე შემთხვევებისთვის

Safari/ITP და მესამე პარტიის შეზღუდვები: ფული მასპინძელში (REST/gRPC), iFrame შინაარსი კომუნიკაბელურია 'postMessess- ის მეშვეობით "; ვებჰუკი მასპინძლისგან, არა iFrame.

მულტიბრენდი: ჭდეები 'tenant _ id/brand _ id/license' სათაურებსა და მოვლენებში; გასაღებები/სერთიფიკატები ცალკე.

დიდი აურზაური (ტურნირები): ვებჰუკების წინ - ბუფერი/ხაზი DLQ- ით; გადატვირთვისას - „no new sessions “/“ pause non-core hooks“.

13) SLO ორიენტირებული ალერტების მაგალითები

Wallet. Authorize p95> ზედიზედ 150 ms 5 წუთი.

შეცდომები 'DUPLICATE/IDEMPOTENCY _ MISMATCH'> 0. 5% 10 წუთში

Webhook lag p99> 180 c თემაზე 'bet. settled`.

Consumer lag in Kafka> 30 s 'wallet. credit.`.

14) დასკვნა

REST, gRPC და ვებჰუკი iGaming- ში არ არის ურთიერთცვალებადი ტექნოლოგიები, არამედ ერთი ოპერაციული მოდელის ნაწილები.

REST/gRPC ინახავს ფულადი ინვარიანტებს: დაბალი ლატენტობა, იდემპოტენტობა, მკაცრი SLA.

ვებჰუკი/ავტობუსი უზრუნველყოფს გამჭვირვალეობას და მასშტაბს: მოვლენები, ტელემეტრია, ინტეგრაცია.

დაამატეთ outbox/CDC, ვერსია, ხელმოწერები და დაკვირვება - და მიიღეთ არქიტექტურა, სადაც ფული სწრაფად და უსაფრთხოდ მოძრაობს, მოვლენები არ იკარგება, ხოლო განახლება უმტკივნეულოდ გადის.