gRPC vs REST в iGaming

1) iGaming konteksti: niyə ümumiyyətlə protokol seçirsiniz

• real vaxt: fid əmsalları, canlı bahislər, streaming kupon/matç statusları, oyunçu limitləri, ani bloklama;
• əməliyyatlar: depozit/çıxarış, dərəcələrin hesablanması, bonuslar, KYC/AML, dəstək biletləri;
• tərəfdaş/B2B inteqrasiya: oyun provayderləri, ödəniş şlüzləri, affiliates, tənzimləyicilər.

Protokoldan asılıdır p99-latentlik, pik altında sabitlik (matçlar, finallar), inteqrasiyanın rahatlığı və istismar dəyəri.

2) Qısa: REST və gRPC nədir

REST/HTTP/JSON: humanitable, universal. Brauzerlər/mobil SDK ilə əla işləyir, CDN cached, asan debage.
gRPC (HTTP/2 + Protobuf): ikili müqavilələr, müştərilərin avtogenerasiyası, uni/bi-directional axını, multipleksinq, ciddi sxemlər. Şəbəkə xidməti onun elementidir.

3) iGaming uyğun harada

gRPC - güclü tərəflər

Canlı oyunlar və trekinq: faktorların axını, matç hadisələri, limitlər (server streaming/bidi).
Daxili mikroservislər: risk mühərriki, kotirovka, antifrodun hesablanması, balans/cüzdan - p99/CPU tələbləri.
Qısa mesajlarla böyük RPS dövriyyəsi (aşağı bayt qiyməti, kiçik GC pressure).
Komandalar və versiyalar arasında ciddi müqavilələr (backward-compat ilə Protobuf).

REST - güclü tərəflər

İctimai və tərəfdaş API: sadə inteqrasiya (curl/Postman), gRPC yığını olmayan tərəfdaşlar.
Browser ön: yerli, heç bir proxy; / ETag/304/CDN cache dəstəyi.
Uzun ömürlü resurslar: oyun kataloqları, profillər, hesabatlar, konfiqurasiyalar.
Tənzimləyici boşaltma: JSON/CSV-uyğunluq şlyuzsuz.

4) Gecikmə və ötürmə qabiliyyəti

gRPC yük ölçüsü (Protobuf) və serial/deserializasiya xərcləri baxımından daha qənaətlidir, qısa və tez-tez çağırışlarda qalib gəlir.
REST/JSON faydalı yükə 30-200% əlavə edir, lakin ictimai GET-də caching və CDN ilə qazanır.

Tövsiyə: DC daxilində/servislərarası - gRPC default; real vaxt istisna olmaqla - REST.

5) Real vaxt: canlı bahislər və kotirovkalar

• gRPC server streaming/bidi: updates, backpressure, pəncərə nəzarət üçün daimi axın.
• gRPC-Web (Envoy vasitəsilə) brauzer üçün, əgər cəbhədə ikili protokol lazımdır.
• WebSocket/SSE + REST: gRPC-Web ekosistemi uyğun deyil və ya proxy olmadan təmiz brauzer lazımdır zaman.

Pattern: daxili - gRPC axınlar kotirovkadan API-şlüzə/edge; - Ön üçün WebSocket/SSE, CRUD üçün REST.

6) İdempotentlik, çatdırılma qaydası və zəmanət

REST: Şlüzdə POST üçün «Idempotency-Key», taymaut zamanı təkrar xidmət; açar - Redis/DB c TTL.
gRPC: müştəri/balanslaşdırıcı səviyyəsində retrajlar + idempotent üsulları ('retriable _ status _ codes') və axın mesajlarında sequence/versiya.
Bahisləri hesablamaq üçün sinkdə Inbox/Outbox + UPSERT istifadə edin (dekuplikasiya və sifariş haqqında məqalələrə baxın) - protokolun özü biznes effektinə zəmanət vermir.

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

Nəqliyyat: TLS/mTLS və mesh, və edge; gRPC-də mTLS (SPIFFE/SPIRE) saxlamaq daha asandır.
Autentifikasiya: Hər iki seçim OAuth2/OIDC dəstəkləyir (JWT in 'Authorization: Bearer'), gRPC üçün - metadata.
İmzalar/NMAS: B2B REST inteqrasiyalarında daha tez-tez.
PII/log: gRPC ikili payload təsadüfən «tökmək» daha çətindir, lakin hər halda maskadan istifadə edin.
Tənzimləyicilər tez-tez insan boşaltma tələb - REST/JSON daha rahat.

8) Müşahidə və istismar

Hər iki format OpenTelemetry ilə mükəmməl işləyir: 'traceparent' (REST )/gRPC interceptors.
gRPC zəngin status/treyler verir; REST - adi HTTP kodları və CDN/WAF qatları.
Şlüzdə: rate limiting/quota, circuit breaker, outlier detection, fault injection - eyni şəkildə mövcuddur (Envoy/Kong/NGINX/Traefik).

9) Uyğunluq və ön

Təmiz brauzer qutudan gRPC danışmır → gRPC-Web və ya REST/WS/SSE.
Mobil müştərilər (iOS/Android) - gRPC müştəriləri mövcuddur, lakin SDK ölçüsü və gizli siyasət bəzən REST itələyir.

10) Qarışıq perimetr memarlıq nümunələri

10. 1 Strategiya «cüt fasad»

Daxili (şərq-qərb): gRPC.
Çıxış (north-south): REST + WS/SSE.
edge (Envoy) transkodinq: bir arxa, iki müştəri.

yaml
Envoy: REST ↔ gRPC transcoding (фрагмент)
typed_per_filter_config:
envoy.filters.http.grpc_json_transcoder:
"@type": type.googleapis.com/envoy.extensions.filters.http.grpc_json_transcoder.v3.GrpcJsonTranscoder proto_descriptor: "descriptors.pb"
services: ["betting.BetsService"]
print_options:
preserve_proto_field_names: true

10. 2 gRPC-Web

Browser → Envoy (gRPC-Web) → gRPC xidməti. Live-widget və admin UI üçün əlverişlidir.

11) Müqavilələr və API təkamülü

Protobuf (gRPC)

Yalnız mesajları genişləndirin (yeni etiketlərlə sahələr əlavə edin), semantika və növləri dəyişdirməyin.

proto syntax = "proto3";
package betting;

service BetsService {
rpc PlaceBet(PlaceBetRequest) returns (PlaceBetResponse);
rpc LiveOdds(EventsFilter) returns (stream OddsUpdate); // серверный стрим
}

message PlaceBetRequest {
string account_id = 1;
string event_id  = 2;
double stake   = 3;
string selection = 4;
string idempotency_key = 5;
}

OpenAPI (REST)

Yol boyunca version '/v1 ', yeni sahələr yalnız isteğe bağlıdır.

yaml openapi: 3.0.3 info: { title: Bets API, version: "1.0" }
paths:
/v1/bets:
post:
operationId: placeBet parameters:
- in: header name: Idempotency-Key required: true schema: { type: string }
requestBody:
required: true content:
application/json:
schema:
$ref: '#/components/schemas/PlaceBetRequest'
responses:
'201': { description: Created }
components:
schemas:
PlaceBetRequest:
type: object required: [accountId, eventId, stake, selection]
properties:
accountId: { type: string }
eventId:  { type: string }
stake:   { type: number, format: double }
selection: { type: string }

12) iGaming Cases: seçmək üçün nə

13) istehsal nüansları

Taymaut/retraj

gRPC: 'per _ try _ timeout', limiti 'max _ attempts', retray yalnız idempotent RPC üçün.
REST: eksponensial backoff, jitter, şlüzdə 429/5xx siyasəti.

Bədən/üsul məhdudiyyəti

REST: sorğu ölçüsü limitləri, 'Content-Type' validasiya.
gRPC: mesaj ölçüsü limitləri, flow control.

Caching

REST: `Cache-Control`, `ETag`.
gRPC: proqram/şlüz səviyyəsində önbellək (unary üçün), axınlar üçün - snapshotlar/kəsiklər.

Müşahidə

Məcburi: log korrelyasiya (request id), span, marşrut/metod üzrə səhv metrikası, p50/p95/p99 paylanması.

14) Anti-nümunələr

«Hər şeyi gRPC-yə köçürün» və birbaşa cəbhəyə verməyə çalışın - gRPC-Web/proxy olmadan bu brauzeri qıracaq.
Yalnız gRPC-lə açıq veb-end-pointlər - tərəfdaşlar düşəcəklər.
REST-pollinq vasitəsilə canlı feed axını - şəbəkə/bekend həddindən artıq yükləmə və yavaş kotirovkalar.
Müştəri səviyyəsində qeyri-idempotent əməliyyatları (bahis/ödəniş) retraj.
/ sequence versiyaları əvəzinə hadisələr sırası üçün fiziki vaxt güvənmək.

15) Protokol seçimi yoxlama siyahısı

• Trafik realtime və ya CRUD/tərəfdaş?
• Müştərilər - brauzer/tərəfdaşlar və ya mikroservislər/mobil SDK?
• Axın tələb olunur (server/bidi)?
• Perimetrdə CDN/caches lazımdır?
• Hansı SLO p99 və büdcə səhvləri?
• Hesabat formatlarına (JSON/CSV) tənzimləyicinin tələbləri varmı?
• İdempotentlik və babanın planı müəyyənləşdirilib?
• API/mesh ilə inteqrasiya hazırdır (mTLS, limitlər, yayım)?
• Version strategiyası və uyğunluq təsdiq?
• Dashboard/Alerts və Match Day zirvələri üçün Test Playbook hazır?

16) Mini Playbook (Game Days)

Match Pik: RPS Live Feeds ikiqat → p99 qiymətləndirmək və mesaj itkisi (axınlar).
Provayderin uğursuzluğu: axının düşməsi - CB/outlier, ön - son snapshot deqradasiya olmalıdır.
Şlüz reqressiyası: gRPC REST yayımını söndürün - fallback (WS/SSE) işləməsini təmin edin.
Şəbəkə gecikmələri/WAN: süni RTT qaldırmaq → zaman və backoff adaptasiya yoxlamaq.
Böyük cisimlər (KYC): limitləri/təkrar yükləmələri yoxlayın, ümumiləşdirin.

17) Nəticələr

Klaster daxilində: gRPC - performans, ciddi müqavilələr və axın üçün defolt.
Perimetrdə: REST (və real-time UI üçün WS/SSE) - geniş uyğunluq üçün defolt.
API-şlyuz (transkodinq, limitlər, autentifikasiya) və service mesh (mTLS, trafik siyasəti) vasitəsilə dünyaları tikirik.
Müvəffəqiyyət - aydın fərqləndirmə ilə qarışıq memarlıqda: daxili axın/aşağı gecikmə, rahatlıq və xaricdən universallıq.