gRPC vs REST в iGaming

1) iGaming контекст: эмне үчүн протоколду тандоо керек

• реалдуу убакыт: FID коэффициенттери, Live коюмдар, агымы купон/матч статусун, оюнчу чектөөлөрдү, заматта бөгөт коюу;
• транзакциялар: депозит/чегерүү, чендерди эсептөө, бонустар, KYC/AML, колдоо үчүн билеттер;
• өнөктөш/B2B интеграциясы: оюн провайдерлери, төлөм шлюздары, аффилиаттар, жөнгө салуучулар.

Протоколго p99-латенттүүлүк, туу чокусунда туруктуулук (беттештер, финалдар), интеграциялардын ыңгайлуулугу жана эксплуатация баасы көз каранды.

2) Кыскача: REST жана gRPC деген эмне

REST/HTTP/JSON: адам окулуучу, универсалдуу. Улуу browser/мобилдик SDK менен иштейт, CDN кэш, жонокой талаш.
gRPC (HTTP/2 + Protobuf): бинардык келишимдер, кардарлардын autogeneration, uni/bi-directional стриминг, мультиплексирлөө, катуу схемалар. Тармак аркылуу тейлөө - анын элементи.

3) Кайда iGaming ылайыктуу

gRPC - күчтүү жактары

Лайв-фиддер жана трекинг: коэффициенттердин агымы, матч окуялары, лимиттер (server streaming/bidi).
Ички микросервистер: тобокелдик кыймылдаткычы, котировщик, антифрод эсеби, баланс/капчык - p99/CPU талаптары.
Кыска билдирүүлөр менен чоң RPS жүгүртүү (төмөн байт баасы, чакан GC-pressure).
Командалар менен версиялардын ортосундагы катуу келишимдер (backward-compat менен Protobuf).

REST - күчтүү жактары

Коомдук жана өнөктөш API: жөнөкөй бириктирүү (curl/Postman), gRPC-стек жок өнөктөштөр.
Browser Front: жергиликтүү, прокси жок; колдоо кэш/ETag/304/CDN.
Узак мөөнөттүү ресурстар: оюн каталогдору, профилдер, отчеттор, конфигурациялар.
Жөнгө чыгаруу: JSON/CSV-шайкештиги жок кулпулары.

4) Жашыруун жана өткөрүү жөндөмдүүлүгү

gRPC пайдалуу жүктүн көлөмү боюнча үнөмдүү (Protobuf) жана сериалдаштыруу/десериалдаштыруу чыгымдары, кыска жана тез-тез чалуулар боюнча утат.
REST/JSON пайдалуу жүктү 30-200% кошот, бирок коомдук GET кэш жана CDN аркылуу утат.

Сунуш: DC ичинде/кызмат аралык - gRPC демейки; - реалдуу убакыт тышкары REST.

5) Реалдуу убакыт: Live коюмдар жана котировкалар

• gRPC server streaming/bidi: updates үчүн туруктуу агым, backpressure, терезе башкаруу.
• gRPC-Web (Envoy аркылуу) браузер үчүн, Эгер фронтто бинардык протокол керек болсо.
• WebSocket/SSE + REST: gRPC-Web экосистемасы туура келбесе же прокси жок таза браузерге муктаж болгондо.

Паттерн: ичинде - gRPC агымдары үчүн API-шлюз/edge; - WebSocket/SSE front үчүн, CRUD үчүн REST.

6) жол-жоболоштуруу, тартиби жана жеткирүү кепилдиги

REST: шлюз POST үчүн "Idempotency-Key", тайм учурунда кайра берүү; ачкыч - Redis/DD c TTL.
gRPC: кардар/баланстоочу денгээлде Retray + демпотенттик ыкмалар ('retriable _ status _ codes') жана агымдык билдирүүлөрдө sequence/версиялоо.
Коюмдарды эсептөө үчүн Inbox/Outbox + UPSERT колдонуңуз.

7) Коопсуздук жана комплаенс

Транспорт: TLS/mTLS жана сетка, жана edge; gRPC бардык жерде mTLS (SPIFFE/SPIRE) сактоого жардам берет.
Аутентификация: эки вариант тең OAuth2/OIDC колдойт (JWT in 'Authorization: Bearer'), gRPC үчүн - метадеректер.
Кол тамгалар/НМАС: B2B REST интеграцияларында көбүрөөк.
PII/Логин: бинардык payload gRPC кыйын кокусунан "төгүп", бирок кандай болгон күндө да маскировка колдонуу.
Жөнгө салуучу көп учурда адам жүктөрдү талап - REST/JSON ыңгайлуу.

8) Байкоо жана пайдалануу

Эки формат OpenTelemetry менен жакшы иштейт: 'traceparent' (REST )/gRPC интерсепторлору.
gRPC бай статусун/трейлер берет; REST - тааныш HTTP коддору жана CDN/WAF катмарлары.
шлюз боюнча: rate limiting/quota, circuit breaker, outlier detection, fault injection - бирдей жеткиликтүү (Envoy/Kong/NGINX/Traefik).

9) шайкештик жана алдыңкы

Таза браузер кутучадан gRPC сүйлөбөйт → gRPC-Web же REST/WS/SSE.
Мобилдик кардарлар (IOS/Android) - gRPC кардарлар жеткиликтүү, бирок SDK өлчөмү жана сактоо саясаты кээде REST түртүп.

10) Архитектуралык аралаш периметри үлгүлөрү

10. 1 Стратегия "кош фасад"

Ичинде (чыгыш-батыш): gRPC.
Сыртка (түндүк-түштүк): REST + WS/SSE.
edge боюнча транскодинг (Envoy): бир арткы, эки кардар.

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-кызматы. Live-виджеттер жана администратор UI үчүн ыңгайлуу.

11) Келишимдер жана АПИнин эволюциясы

Protobuf (gRPC)

Билдирүүлөрдү кеңейтүү (жаңы тегдер менен талааларды кошуу), семантикасын жана түрлөрүн өзгөртпөө.

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 ', жаңы талаалар гана кошумча.

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: тандоо үчүн эмне

13) өндүрүштүк нюанстар

Таймауттар/ретрациялар

gRPC: 'per _ try _ timeout', чектөө 'max _ attempts', retry гана демпотенттик RPC үчүн.
REST: экспоненциалдык backoff, Jitler, 429/5xx-шлюз саясаты.

Дене/ыкма чектөө

REST: суроо өлчөмү боюнча чектер, 'Content-Type' validation.
gRPC: билдирүүлөрдүн көлөмү боюнча лимиттер, flow control.

Кэштоо

REST: `Cache-Control`, `ETag`.
gRPC: колдонмо/шлюз деңгээлинде кэш (unary үчүн), агымдар үчүн - снапшоттор/тилкелер.

Байкоо

Милдеттүү: логикалык байланыштар (request id), уктап, маршрут/ыкма боюнча ката көрсөткүчтөрү, p50/p95/p99 бөлүштүрүү.

14) Анти-үлгүлөрү

"Баарын gRPCге кайра жазуу" жана түздөн-түз фронтко берүүгө аракет кылуу - gRPC-Web/прокси жок бул браузерди бузат.
Коомдук Web EndPoints гана gRPC - өнөктөштөр түшүп калат.
REST-поллинг аркылуу LiveFeed агымы - тармак/бекенд жана жай котировкаларды ашыкча жүктөө.
Кардардын деңгээлинде демпотенттик эмес операцияларды (коюмду/төлөмдү түзүү) ретрациялоо.
/ sequence ордуна окуялардын тартиби үчүн физикалык убакыт таянуу.

15) Протокол тандоо чек-тизмеси

• Traffic realtime же CRUD/өнөктөш?
• Кардарлар - браузер/өнөктөштөр же микросервис/мобилдик SDK?
• агымы талап кылынат (server/bidi)?
• периметри боюнча CDN/кэш керек?
• Кандай SLO p99 жана бюджет каталар?
• Отчеттуулук форматтары (JSON/CSV) үчүн жөнгө салуучу талаптар барбы?
• Демпотенттик жана чоң атанын планы аныкталганбы?
• API шлюз/mesh менен интеграция даяр (mTLS, лимиттер, берүү)?
• Версия стратегиясы жана шайкештиги бекитилген?
• Dashboard/Alerty жана сыноо Playbook "матч күнү" чокулары даяр?

16) Mini Playbook (Оюн күндөрү)

Матч-чокусу: эки эсе RPS LiveFeed → баа p99 жана жоготуу билдирүүлөр (агымдар).
Провайдердин ийгиликсиздиги: апстримдин кулашы - CB/outlier ажыратылышы керек, фронт - акыркы снапшотко деградация.
Gateway Regress: fallback (WS/SSE) иштеп жаткандыгын текшерип gRPC REST берүү өчүрүү.
Network кечигүү/WAN: жасалма RTT жогорулатуу → убакыт жана backoff ылайыкташтырууну текшерүү.
Big Body (KYC): чектөөлөрдү/көп жүктөөлөрдү текшерүү, кыскача.

17) Натыйжалары

Кластердин ичинде: gRPC - аткаруу, катуу келишимдер жана стриминг үчүн дефолт.
Периметрде: REST (жана WS/SSE үчүн реалдуу убакыт UI) - кеңири шайкештик үчүн дефолт.
Биз API-шлюз (транскодинг, лимиттер, аутентификация) жана service mesh (mTLS, трафик саясаты) аркылуу дүйнөлөрдү тикебиз.
Ийгилик - так ажыратуу менен аралаш архитектурада: ичиндеги стриминг/төмөн латенттүүлүк, сырткы ыңгайлуулук жана универсалдуулук.