gRPC vs RESZT iGaming

1) Kontekst iGaming: dlaczego w ogóle wybrać protokół

• w czasie rzeczywistym: kursy kanałów, zakłady na żywo, statusy kuponu/meczu strumieniowego, limity gracza, zamki błyskawiczne;
• transakcje: depozyt/wypłata, obliczanie stawek, premie, KYC/AML, bilety na wsparcie;
• integracje partner/B2B: dostawcy gier, bramy płatnicze, podmioty powiązane, organy regulacyjne.

Opóźnienie P99, stabilność pod szczytami (mecze, finały), łatwość integracji i koszt działania zależą od protokołu.

2) Krótki: co to jest REST i gRPC

REST/HTTP/JSON: czytelny dla ludzi, uniwersalny. Działa świetnie z przeglądarek/SDK mobilnych, CDN buforowane, łatwe do debugowania.
gRPC (HTTP/2 + Protobuf): kontrakty binarne, autogeneracja klientów, uni/dwukierunkowy streaming, multipleksowanie, ścisłe schematy. Obsługa przez sieć jest jego elementem.

3) W stosownych przypadkach w iGaming

gRPC - mocne strony

Żywe kanały i śledzenie: współczynniki strumieniowe, zdarzenia dopasowujące, limity (strumieniowanie serwera/bidi).
Mikroservice wewnętrzne: silnik ryzyka, notowania, ocena oszustw, bilans/portfel - wymagania p99/CPU.
Duży obrót RPS z krótkimi wiadomościami (niska cena za bajt, małe ciśnienie GC).
Ścisłe umowy między zespołami i wersjami (Protobuf z wstecznym kompatem).

RESZTA - Mocne strony

Interfejsy API publiczne i partnerskie: prosta integracja (curl/Postman), partnerzy bez stosu gRPC.
Front przeglądarki: native, no proxy ;/ ETag/304/CDN cache support.
Długotrwałe zasoby: katalogi gier, profile, raporty, konfiguracje.
Przesyłki regulacyjne: kompatybilność JSON/CSV bez bram.

4) Opóźnienie i przepustowość

gRPC jest bardziej ekonomiczne pod względem wielkości ładunku (Protobuf) i kosztów serializacji/deserializacji, i korzyści z krótkich i częstych połączeń.
REST/JSON dodaje 30-200% do ładunku, ale korzysta z buforowania i CDN na publicznych BP.

Zalecenie: domyślnie wewnątrz DC/inter-service - gRPC; na zewnątrz - REST, z wyjątkiem czasu rzeczywistego.

5) Czas rzeczywisty: stawki i notowania na żywo

• gRPC server streaming/bidi: stały strumień do aktualizacji, backpressure, sterowanie oknem.
• gRPC-Web (via Envoy) dla przeglądarki, jeśli potrzebujesz protokołu binarnego z przodu.
• WebSocket/SSE + REST: gdy ekosystem gRPC-Web nie jest odpowiedni lub potrzebujesz czystej przeglądarki bez serwera proxy.

Wzór: wewnątrz - strumienie gRPC od cytatu do bramy/krawędzi API; na zewnątrz - WebSocket/SSE dla przodu, REST dla CRUD.

6) Gwarancje idempotencji, zamówienia i dostawy

ODPOCZYNEK: „Idempotency-Key” dla POST na bramie, ponowne podawanie na czas; klucz - w Redis/DB z TTL.
gRPC: poziom klienta/balancera przekłada się + metody idempotentne ('retriable _ status _ codes') oraz sekwencja/wersioning w wiadomościach strumieniowych.
Aby obliczyć stawki, użyj skrzynki odbiorczej/skrzynki odbiorczej + UPSERT na siniaku (patrz artykuły o deduplice i zamówieniu) - sam protokół nie gwarantuje efektu biznesowego.

7) Bezpieczeństwo i zgodność

Transport: TLS/mTLS zarówno w oczkach, jak i na krawędzi; w gRPC łatwiej jest wszędzie trzymać mTLS (SPIFFE/SPIRE).
Uwierzytelnianie: obie opcje obsługują OAuth2/OIDC (JWT w 'Authorization: Bearer'), dla gRPC - metadane.
Podpisy/NMAS: częściej w integracjach B2B REST.
PII/logowanie: binarny ładunek gRPC są trudniejsze przypadkowo „rozlać” do dzienników, ale używać przebrania i tak.
Regulatory często wymagają rozładunku człowieka - REST/JSON jest wygodniejszy.

8) Obserwowalność i działanie

Oba formaty świetnie współpracują z OpenTelemetry: 'traceparent' (REST )/interseptorami gRPC.
gRPC zapewnia bogate statusy/przyczepy; REST - znane kody HTTP i warstwy CDN/WAF.
Na bramce: ograniczenie prędkości/kontyngent, wyłącznik, wykrywanie obwodów, wtryskiwanie usterek - równie dostępne (wysłannik/Kong/NGINX/Traefik).

9) Kompatybilność i przód

Czysta przeglądarka nie mówi gRPC z pudełka → gRPC-Web lub REST/WS/SSE.
Klienci mobilni (iOS/Android) - klienci gRPC są dostępni, ale rozmiar SDK i zasady przechowywania czasami naciskają na REST.

10) Mieszane wzory architektoniczne obwodu

10. 1 Strategia podwójnej elewacji

Wewnątrz (wschód-zachód): gRPC.
na zewnątrz (północ-południe): REST + WS/SSE.
Transkodowanie do krawędzi (Wysłannik): jeden backend, dwóch klientów.

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

→ Przeglądarka wysłannika (gRPC-Web) → Usługa gRPC. Wygodne dla widżetów na żywo i administratora UI.

11) Kontrakty i ewolucja API

Protobuf (gRPC)

Tylko rozwiń wiadomości (dodaj pola z nowymi znacznikami), nie zmieniaj semantyki i typów.

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)

Wersioning ścieżką '/v1 ', nowe pola są tylko opcjonalne.

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: Co wybrać

13) Niuanse produkcyjne

Zmiany czasu/rekolekcje

gRPC: 'per _ try _ timeout', limit 'max _ attempts', przekłada się tylko na idempotentne RPC.
REST: wykładnicze backoff, jitter, 429/5xx polityki na bramce.

Ograniczenie ciała/metody

REST: limit wielkości żądania, walidacja „Content-Type”.
gRPC: limity wielkości wiadomości, kontrola przepływu.

Buforowanie

ODPOCZYNEK: „Cache-Control”, „ETag”.
gRPC: pamięć podręczna na poziomie aplikacji/bramy (dla unary), dla strumieni - migawki/plasterki.

Obserwowalność

Obowiązkowe: dziennik korelacji (id żądania), przęsła, mierniki błędów trasy/metody, dystrybucja p50/p95/p99.

14) Anty-wzory

„Przepisz wszystko na gRPC” i spróbuj dać do przodu bezpośrednio - bez gRPC-Web/proxy, to złamie przeglądarkę.
Publiczne punkty końcowe sieci są tylko gRPC - partnerzy odpadną.
Transmisja na żywo przez REST sondaż - przeciążenie sieci/backend i powolne cytaty.
Wycofaj transakcje nieidempotentne (tworzenie/płatność stawek) na poziomie klienta.
Polegaj na czasie fizycznym dla kolejności zdarzeń zamiast wersji/sekwencji.

15) Lista kontrolna wyboru protokołu

• Czas rzeczywisty lub ruch CRUD/partner?
• Przeglądarka/Partner lub Microservices/Mobilni klienci SDK?
• Wymagaj przesyłania strumieniowego (serwer/bidi)?
• Potrzebujesz CDN/bufora na obwodzie?
• Jakie są p99 SLO i budżet błędów?
• Czy istnieje wymóg regulacyjny dotyczący formatów sprawozdawczych (JSON/CSV)?
• Zdefiniowany plan idempotencji i deduplikacji?
• Integracja z bramą API/siatką gotową (mTLS, limity, tłumaczenie)?
• Czy strategia weryfikacji i kompatybilności jest zatwierdzona?
• Czy deski rozdzielcze/alerty i playbooks testowe są gotowe do pików match-day?

16) Mini Playbooks (Dni gry)

Szczyt meczu: podwójne kanały RPS na żywo → ocenić p99 i utratę wiadomości (strumienie).
Awaria dostawcy: upadek w górę strumienia - CB/outlier musi zostać wyeliminowany, przód musi ulec degradacji do ostatniego migawki.
Regres bramki - Wyłączyć tłumaczenie gRPC i REST - Sprawdź, czy WS/SSE działa.
Opóźnienia sieci/WAN: sztucznie podnieść RTT → sprawdzić dostosowanie czasu i backoff.
Duże ciała (KYC): sprawdź limity/wiele plików do pobrania, podsumuj.

17) Kwoty całkowite

Wewnątrz klastra: gRPC - domyślnie dla wykonania, ścisłych umów i streamingu.
Na obwodzie: REST (i WS/SSE dla interfejsu użytkownika w czasie rzeczywistym) - domyślnie dla szerokiej kompatybilności.
Szwy światów przez bramę API (transkodowanie, limity, uwierzytelnianie) i siatkę serwisową (mTLS, polityka ruchu).
Sukces - w architekturze mieszanej z wyraźnym wyróżnieniem: strumieniowanie/niskie opóźnienia wewnątrz, wygoda i wszechstronność na zewnątrz.