gRPC vs REST в iGaming

1) iGaming konteksti: nega umuman protokolni tanlash kerak

• real vaqt: koeffitsiyentlar, hayot stavkalari, kupon/o’yin maqomlarining strimingi, o’yinchi limitlari, bir zumda blokirovka qilish;
• tranzaksiyalar: depozit/chiqarish, stavkalarni hisoblash, bonuslar, KYC/AML, qo’llab-quvvatlash uchun chiptalar;
• sheriklik/V2V integratsiyasi: o’yin provayderlari, to’lov shlyuzlari, affiliatlar, regulyatorlar.

Protokolga p99-latentlik, pik ostidagi barqarorlik (oʻyinlar, final), integratsiya qulayligi va foydalanish narxi bogʻliq.

2) Qisqacha: REST va gRPC nima

REST/HTTP/JSON: inson o’qiydigan, universal. SDK brauzerlari/mobil kompyuterlari bilan juda yaxshi ishlaydi, CDN keshlanadi, debaj qilish oson.
gRPC (HTTP/2 + Protobuf): binar shartnomalar, mijozlarning avtogeneratsiyasi, uni/bi-directional striming, multiplekslash, qat’iy sxemalar. Tarmoq orqali xizmat ko’rsatish - uning elementidir.

3) iGaming’da nima oʻrinli

gRPC - kuchli tomonlar

Hayot-fid va treking: koeffitsiyentlar oqimi, o’yin voqealari, limitlar (server streaming/bidi).
Ichki mikroservislar: tavakkal-dvigatel, kotirovkachi, antifrodning skoringi, balans/hamyon - p99/CPU qo’yiladigan talablar.
Qisqa xabarli katta aylanma RPS (past bayt narxi, kichik GC-pressure).
Jamoalar va versiyalar o’rtasidagi qat’iy shartnomalar (Protobuf bilan backward-compat).

REST - kuchli tomonlari

Ommaviy va sheriklik API: oddiy integratsiya (curl/Postman), gRPC-steksiz sheriklar.
Brauzer jabhasi: mahalliy, proksisiz; / ETag/304/CDN keshini qoʻllab-quvvatlash.
Uzoq davom etadigan resurslar: oʻyin kataloglari, profillar, hisobotlar, konfiguratsiyalar.
Regulyator tushirish: JSON/CSV-mosligi shlyuzlarsiz.

4) Latentlik va o’tkazish qobiliyati

gRPC foydali yuk hajmi (Protobuf) va seriallashtirish/deserizatsiya xarajatlari jihatidan tejamkor, qisqa va tez-tez chaqiruvlarda g’alaba qozonadi.
REST/JSON foydali yukga 30-200% qo’shadi, lekin ommaviy GETda keshlash va CDN orqali g’alaba qozonadi.

Tavsiya: DC/servislararo - gRPC andoza; tashqariga - real vaqtdan tashqari REST.

5) Real vaqt: hayot stavkalari va kotirovkalari

• gRPC server streaming/bidi: yangilanish, backpressure, oynani boshqarish uchun doimiy oqim.
• gRPC-Web (Envoy orqali) brauzer uchun, agar frontda binar protokol kerak boʻlsa.
• WebSocket/SSE + REST: gRPC-Web ekotizimi mos kelmasa yoki proksisiz sof brauzer kerak boʻlsa.

Pattern: ichki - gRPC kotirovkachidan API-shlyuzga/edge oqimlari; - front uchun WebSocket/SSE, CRUD uchun REST.

6) Idempotentlik, yetkazib berish tartibi va kafolatlari

REST: «Idempotency-Key» uchun POST shlyuzda, taymautda qayta berish; kalit - Redis/DB c TTL.
gRPC: mijoz/balanschi darajasidagi retrajlar + idempotent usullar (’retriable _ status _ codes’) va striming xabarlarida sequence/versiyalash.
Stavkalarni hisoblash uchun sinkdagi Inbox/Outbox + UPSERT dan foydalaning (dekuplikatsiya va tartib haqidagi maqolalarga qarang) - protokolning o’zi biznes samarasini kafolatlamaydi.

7) Xavfsizlik va komplayens

Transport: TLS/mTLS ham mesh, ham edge; gRPC da mTLS (SPIFFE/SPIRE) ni hamma joyda saqlash osonroq.
Autentifikatsiya: ikkala variant ham OAuth2/OIDC (JWT v’Authorization: Bearer’), gRPC uchun esa meta-ma’lumotlarni qo’llab-quvvatlaydi.
Imzolar/NMAS: ko’pincha B2B REST integratsiyalarida.
PII/loging: gRPC binar payload tasodifan loglarga «quyish» qiyinroq, lekin har qanday holatda ham niqobdan foydalaning.
Regulyatorlar ko’pincha odamlarni tushirishni talab qiladi - REST/JSON qulayroq.

8) Kuzatish va foydalanish

Ikkala format ham OpenTelemetry:’traceparent’(REST )/gRPC interseptorlari bilan juda yaxshi ishlaydi.
gRPC boy maqom/treylerlar beradi; REST - tanish HTTP kodlari va CDN/WAF qatlamlari.
Shlyuzda: rate limiting/quota, circuit breaker, outlier detection, fault injection - bir xil darajada mavjud (Envoy/Kong/NGINX/Traefik).

9) Muvofiqlik va front

Sof brauzer → gRPC-Web yoki REST/WS/SSE qutisidan gRPC demaydi.
Mobil mijozlar (iOS/Android) - gRPC mijozlari mavjud, ammo SDK hajmi va stor siyosati ba’zan RESTni talab qiladi.

10) Aralash perimetr arxitektura patternlari

10. 1 «Ikki fasad» strategiyasi

Ichki (east-west): gRPC.
Tashqi (north-south): REST + WS/SSE.
edge (Envoy) da transkoding: bitta orqa, ikkita mijoz.

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

Brauzer → Envoy (gRPC-Web) → gRPC-servis. Live-vidjetlar va ma’muriy UI uchun qulay.

11) Kontraktlar va API evolyutsiyasi

Protobuf (gRPC)

Faqat xabarlarni kengaytiring (yangi teglar bilan maydonlarni qoʻshing), semantika va turlarni oʻzgartirmang.

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)

’/v1’yoʻlida versionlash, yangi maydonlar faqat ixtiyoriydir.

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 keyslari: nimani tanlash kerak

13) Ishlab chiqarish nuanslari

Taymautlar/retralar

gRPC:’per _ try _ timeout’, cheklash’max _ attempts’, retrajlar faqat idempotent RPC uchun.
REST: eksponensial backoff, jitter, shlyuzdagi 429/5xx siyosati.

Tana/usul chegarasi

REST: Soʻrov oʻlchami chegarasi,’Content-Type’validatsiyasi.
gRPC: xabar oʻlchami chegarasi, flow control.

Keshlash

REST: `Cache-Control`, `ETag`.
gRPC: ilova/shlyuz darajasidagi kesh (unary uchun), strimlar uchun - snapshotlar/kesmalar.

Kuzatish

Majburiy: log korrelyatsiyalari (request id), spanlar, yo’nalish/usul bo’yicha xato metrikasi, p50/p95/p99 taqsimoti.

14) Anti-patternlar

«Hamma narsani gRPCga qayta yozish» va gRPC-Web/proksisiz to’g’ridan-to’g’ri frontga berishga harakat qilish brauzerni buzadi.
Ochiq veb-endpointlar faqat gRPC - sheriklar tushadi.
Life-fidlarni REST-polling orqali oqizish - tarmoqni/bekendni qayta yuklash va sekin kotirovkalar.
Mijoz darajasida indempotent bo’lmagan operatsiyalarni (stavka/to’lov yaratish) retratsiya qilish.
/ sequence versiyasi oʻrniga hodisalar tartibi uchun jismoniy vaqtga tayanish.

15) Bayonnomani tanlash chek-varaqasi

• Realtime yoki CRUD/sherikmi?
• Mijozlar - brauzer/sheriklar yoki mikroservislar/mobil SDK?
• Oqim (server/bidi) talab qilinadimi?
• Perimetrdagi CDN/keshlar kerakmi?
• Qanday SLO p99 va byudjet xatolari?
• Regulyatorning hisobot formatlariga (JSON/CSV) talablari bormi?
• Idempotentlik va bobo rejasi aniqlanganmi?
• API/mesh bilan integratsiya tayyor (mTLS, limitlar, translyatsiya)?
• Version va muvofiqlik strategiyasi tasdiqlanganmi?
• Dashbordlar/alertlar va «match-kun» cho’qqilariga test pleybuklari tayyormi?

16) Mini-pleybuklar (Game Days)

O’yin cho’qqisi: RPS life-fidlarni ikki baravar oshirish → p99 bahosi va xabar yo’qotishlari (strimlar).
Provayderning muvaffaqiyatsizligi: apstrimning pasayishi - CB/outlier chiqarib tashlanishi, front oxirgi snapshotga tushishi kerak.
Fallback (WS/SSE) ishlayotganiga ishonch hosil qiling.
Tarmoq kechikishlari/WAN: sun’iy ravishda RTT → taymaut va backoff moslashuvini tekshirish.
Katta tanalar (KYC): limitlarni tekshirish/ko’p marta yuklash, xulosa chiqarish.

17) Yakunlar

Klaster ichida: gRPC - unumdorlik, qat’iy kontraktlar va striming uchun defolt.
Perimetrda: REST (va WS/SSE for real-time UI) - keng moslik uchun defolt.
Biz dunyolarni API-shlyuz (transkoding, limitlar, autentifikatsiya) va service mesh (mTLS, trafik siyosati) orqali tikamiz.
Muvaffaqiyat aralash arxitekturada aniq chegaralangan: ichki oqim/past latentlik, tashqi tomondan qulaylik va universallik.