gRPC vs REST в iGaming

1) iGaming контекст: протоколды таңдаудың қажеті жоқ

• нақты уақыт: коэффициенттер фидтері, лайв-ставкалар, купон/матч статустарының стримингі, ойыншының лимиттері, жедел бұғаттау;
• транзакциялар: депозит/шығару, мөлшерлемелерді есептеу, бонустар, KYC/AML, қолдау үшін тикеттер;
• серіктестік/В2В интеграция: ойын провайдерлері, төлем шлюздері, аффилиаттар, реттеушілер.

Хаттамаға p99-латенттілік, шыңдар астындағы тұрақтылық (матчтар, финалдар), интеграцияның қолайлылығы және пайдалану құны байланысты.

2) Қысқаша: REST және gRPC дегеніміз не?

REST/HTTP/JSON: адам оқитын, әмбебап. Браузерлермен/мобильді SDK-мен жақсы жұмыс істейді, CDN кэшеленеді, дебаж жасау оңай.
gRPC (HTTP/2 + Protobuf): бинарлық келісімшарттар, клиенттердің автогенерациясы, uni/bi-directional стриминг, мультиплексиялау, қатаң схемалар. Желі бойынша сервис-к-сервис - оның элементі.

3) iGaming-те не орынды

gRPC - күшті жақтары

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

REST - күшті жақтары

Қоғамдық және серіктестік API: қарапайым интеграция (curl/Postman), gRPC-стексіз серіктестер.
Шолғыш фронты: жеке, проксисіз; / ETag/304/CDN кэшін қолдау.
Ұзақ өмір сүретін ресурстар: ойындар каталогтары, профильдер, есептер, конфигурациялар.
Реттегіш түсіру: JSON/CSV-шлюздерсіз үйлесімділігі.

4) Жасырындылық және өткізу қабілеті

gRPC пайдалы жүктеме көлемі (Protobuf) және сериалдау/десериалдау шығындары бойынша үнемді, қысқа және жиі шақыруларда жеңеді.
REST/JSON пайдалы жүктемеге 30-200% қосады, бірақ кешіктіру және көпшілік GET CDN арқылы ұтады.

Ұсыным: DC ішінде/қызмет аралық - әдепкі gRPC; сыртқа - нақты уақыттан басқа, REST.

5) Нақты уақыт: лайв-ставкалар және баға белгілеулер

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

Паттерн: ішінде - gRPC ағыны баға белгілеушіден API-шлюзге/edge; сыртқа - фронт үшін WebSocket/SSE, CRUD үшін REST.

6) Сәйкестігі, жеткізу тәртібі мен кепілдіктері

REST: «Idempotency-Key» шлюздегі POST үшін, таймаут кезінде қайта беру; кілт - Redis/ДБ c TTL.
gRPC: клиент/теңгеруші деңгейіндегі ретрациялар + демпотенттік әдістер ('retriable _ status _ codes') және стриминг хабарламаларындағы sequence/нұсқалау.
Ставкаларды есептеу үшін синкте Inbox/Outbox + UPSERT пайдаланыңыз (Дедупликация және тәртіп туралы мақаланы қараңыз) - хаттаманың өзі бизнес-тиімділікке кепілдік бермейді.

7) Қауіпсіздік және комплаенс

Көлік: TLS/mTLS және mesh, және edge; gRPC-те mTLS (SPIFFE/SPIRE) барлық жерде ұстау оңай.
Аутентификация: екі нұсқа да OAuth2/OIDC қолдайды (JWT в 'Authorization: Bearer'), gRPC үшін - метадеректер.
Қолтаңбалар/НМАС: жиі B2B REST-интеграцияларында.
PII/логин: gRPC бинарлық payload кездейсоқ логинге «төгу» қиынырақ, бірақ кез келген жағдайда бүркемелеуді пайдаланыңыз.
Реттегіштер көбінесе адамдарды түсіруді талап етеді - 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-Web немесе REST/WS/SSE қорабынан gRPC сөйлемейді.
Мобильді клиенттер (iOS/Android) - gRPC клиенттері қол жетімді, бірақ SDK өлшемі мен ескіру саясаты кейде REST-ге итереді.

10) Аралас периметрдегі сәулеттік паттерндер

10. 1 «Қос қасбет» стратегиясы

Ішінде (east-west): gRPC.
Сыртқа (north-south): 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

Браузер → Envoy (gRPC-Web) → gRPC-сервис. Live-виджеттер мен әкімшілік UI үшін қолайлы.

11) Келісімшарттар және API эволюциясы

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 кейстері: не таңдау керек

13) Өндірістік нюанстар

Таймауттар/ретрайлер

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

Денені/әдісті шектеу

REST: сұрау өлшемінің шектері, 'Content-Type' валидациясы.
gRPC: хабарлар өлшемінің шектері, flow control.

Кэштеу

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

Бақылау мүмкіндігі

Міндетті: корреляциялар (request id), спандар, маршрут/әдіс бойынша қателер өлшемдері, p50/p95/p99 бөлу.

14) Қарсы үлгілер

«Барлығын gRPC-ке көшіріп алу» және тікелей фронтқа беруге тырысу - gRPC-Web/прокси-сіз бұл браузерді бұзады.
Көпшілік веб-эндпоинттер тек gRPC - серіктестер құлап қалады.
REST-поллинг арқылы лайв-фидтерді ағызу - желіні/бекендті қайта тиеу және баяу баға белгілеу.
Клиент деңгейінде демпотенттік емес операцияларды (ставка/төлем жасау) ретрациялауға.
/ sequence нұсқаларының орнына оқиғалар тәртібі үшін нақты уақытқа сүйену.

15) Хаттаманы таңдау чек-парағы

• Трафик realtime немесе CRUD/серіктес?
• Клиенттер - браузер/серіктестер немесе микросервистер/мобильді SDK?
• Стриминг (server/bidi) қажет пе?
• Периметрдегі CDN/кэштер қажет пе?
• Қандай SLO p99 және бюджет қателері бар?
• Реттеушінің есептілік пішімдеріне (JSON/CSV) талаптары бар ма?
• Идемпотенттілік пен атаның жоспары анықталды ма?
• API шлюзімен/mesh интеграциясы дайын ма (mTLS, лимиттер, трансляция)?
• Нұсқалау және үйлесімділік стратегиясы бекітілді ме?
• Дашбордтар/алерттар және «матч-күннің» шыңына тест-плейбуктер дайын ба?

16) Шағын ойнатқыштар (Game Days)

Матч-пик: RPS лайв-фидтерін екі еселеу → p99 бағалау және хабарламаларды жоғалту (ағымдар).
Провайдердің сәтсіздігі: апстримнің құлдырауы - CB/outlier соңғы снапшотқа кетуі керек.
Шлюз регрессі: gRPC REST трансляциясын өшіру - fallback (WS/SSE) жұмыс істеп тұрғанына көз жеткізу.
Желілік кідірістер/WAN: RTT → таймауттар мен backoff бейімделуін тексеру.
Үлкен денелер (KYC): лимиттерді/бірнеше рет жүктеуді, қорытындылауды тексеру.

17) Қорытынды

Кластер ішінде: gRPC - өнімділік, қатаң келісімшарттар және стриминг үшін дефолт.
Периметрде: REST (және WS/SSE үшін real-time UI) - кең үйлесімділік үшін дефолт.
Әлемді API-шлюз (транскодинг, лимиттер, аутентификация) және service mesh (mTLS, трафик саясаты) арқылы тігеміз.
Табысқа - аралас архитектурада нақты ажыратумен: ішіндегі стриминг/төмен латенттілік, сырттан ыңғайлылық пен әмбебаптық.