gRPC vs REST в iGaming

1) Contesto iGaming: perché scegliere un protocollo?

• tempo reale: i fidi dei coefficienti, le scommesse live, lo streaming degli stati del coupon/partita, i limiti del giocatore, i blocchi istantanei;
• transazioni: deposito/ritiro, calcolo delle scommesse, bonus, KYC/AML, tickets di supporto;
• partner/B2B integrazioni: provider di giochi, gateway, affiliati, regolatori.

Il protocollo dipende da p99-latitanza, stabilità sotto i picchi (partite, finali), facilità di integrazione e costo di utilizzo.

2) Breve: cosa sono RESTE e gRPC

REST- HTTP/JSON - Umano, universale. Funziona perfettamente con i browser/SDK mobile, la cache CDN è facile da ritardare.
gRPC (HTTP/2 + Protobuf): contratti binari, autoregolamentazione dei clienti, uni/bi-directional streaming, multiplexing, diagrammi rigorosi. Il servizio di accesso alla rete è il suo elemento.

3) Se necessario nel iGaming

gRPC - Punti di forza

Fide Lave e tracking: stringa i coefficienti, gli eventi di partita, i limiti (server streaming/bidi).
Microservizi interni: motore di rischio, quotatore, antifrode, bilanci/portafogli - requisiti p99/CPU.
RPS con messaggi brevi (basso prezzo per byte, piccolo GC-pressure).
Contratti rigorosi tra comandi e versioni (Protobuf con backward-compat).

REST- Punti di forza

API pubblica e partner: semplice integrazione (curl/Postman), partner senza gRPC stack.
Fronte browser: nativo, senza proxy; Supporto cache/ETag/304/CDN.
Risorse a lunga vita: cataloghi di gioco, profili, report, configurazioni.
Download regolatori: compatibilità JSON/CSV senza gateway.

4) Latitanza e larghezza di banda

gRPC più economico in termini di carico utile (Protobuf) e costi di serializzazione/deserializzazione, vince su chiamate brevi e frequenti.
REST/JSON aggiunge il 30-200% al carico utile, ma vince con la cache e il CDN su GET pubblici.

Raccomandazione: all'interno del DC/ fuori - RESTA, tranne che in tempo reale.

5) Tempo reale: le scommesse live e la quotazione

• gRPC server streaming/bidi: flusso costante per gli aggiornamenti, backpressure, controllo della finestra.
• gRPC-Web (tramite Avvoy) per il browser se si desidera un protocollo binario sul fronte.
• WebSocket/SSE + gRPC-Web - Quando un ecosistema non è adatto o ha bisogno di un browser pulito senza proxy.

Pattern: all'interno ci sono strike da quotatore a API-gateway/edge; fuori - per il fronte, per CRUD.

6) Idempotenza, ordine e garanzia di consegna

REST'Idempotency-Key ', per POST sul gateway, riutilizzo durante il timeout; la chiave è in Redis/Database con TTL.
gRPC: retrai a livello di client/bilanciatore + metodi idempotati ('retriable _ status _ codes') e sequence/versioning nei messaggi di streaming.
Per calcolare le scommesse, utilizzare Inbox/Outbox + UPSERT sul nastro (vedere articoli su deduplicazione e ordine) - il protocollo di per sé non garantisce alcun effetto aziendale.

7) Sicurezza e compliance

Trasporti: sia in mesh che in edge; nel gRPC è più facile tenere un mTLS ovunque (SPIFFE/SPIRE).
Autenticazione: entrambe le opzioni supportano OAuth2/OIDC (JWT in Authorization: Bearer) e i metadati per gRPC.
Firme/NMAS: più frequente nelle integrazioni REST. B2B.
PII/Loging - payload binari è più difficile per caso «versare» nei loghi, ma utilizzare il travestimento in ogni caso.
I regolatori richiedono spesso scarichi umani - REST/JSON è più conveniente.

8) Osservabilità e funzionamento

Entrambi i formati funzionano perfettamente con «traceparent» (REST)/intersettori gRPC.
gRPC dà ricchi statuti/roulotte; REST- codici HTTP abituali e scorciatoie CDN/WAF.
Nel gateway: rate limiting/quote, circuito breaker, outlier detection, fault ingection - sono ugualmente disponibili (Invoy/Kong/NGINX/Traefik).

9) Compatibilità e fronte

Il browser pulito non dice gRPC dalla scatola → o gRPC-Web/WS/SSE.
Client mobili (iOS/Android) - I clienti grpc sono disponibili, ma la dimensione SDK e la politica di store a volte spingono verso il REST.

10) Cartelli architettonici perimetro misto

10. 1 Strategia doppia facciata

Interno (east-west) - gRPC.
Fuori (north-sud): REST + WS/SSE.
Trascoding su edge (Avvoy) - un backend, due client.

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

Il browser di Avvoy ( ) è un servizio gRPC. Comodo per widget live e UI adminesi.

11) Contratti e evoluzione API

Protobuf (gRPC)

Espandere solo i messaggi (aggiungere campi con nuovi tag), non modificare semantici e tipi.

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)

Versioning lungo il percorso '/v1 ', i nuovi campi sono solo opzionali.

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) Le : cosa scegliere

13) Sfumature di produzione

Timeout/retrai

gRPC: «per _ try _ timeout», limitare «max _ attempts», retrai solo per RPC idempotati.
REST. backoff esponenziale, jitter, 429/5xx-policy sul gateway.

Vincolo corpo/metodo

Restrizioni per la dimensione della query, «Content-Type» convalida.
gRPC: limiti per dimensione dei messaggi, flow control.

Cache

REST: `Cache-Control`, `ETag`.
gRPC: kash a livello di applicazione/gateway (unary), per striam - snapshot/taglio.

Osservabilità

Obbligatori: riepilogo di correlazione (richiest id), span, metriche di errore percorso/metodo, distribuzione p50/p95/p99.

14) Anti-pattern

«Riscrivere tutto sul gRPC» e cercare di dare il fronte direttamente - senza gRPC-Web/proxy, questo distruggerà il browser.
Endpoint pubblici solo gRPC-M - partner si ritireranno.
Stravolgere i fide lave attraverso il REST's polling - surriscaldamento della rete/becenda e quote lente.
Ritrattare le transazioni non idonee (creazione di una puntata/pagamento) a livello di client.
Affidarsi al tempo fisico per l'ordine degli eventi invece delle versioni/sequence.

15) Assegno-foglio di selezione del protocollo

• Traffico realtime o CRUD/partner?
• Client - browser/partner o microservizi/SDK mobile?
• È necessario uno streaming (server/bidi)?
• Hai bisogno di CDN/cassetti nel perimetro?
• Quali SLO p99 e budget degli errori?
• Esistono i requisiti del regolatore per i formati di reporting (JSON/CSV)?
• Il piano di idempotenza e deduplicazione è definito?
• L'integrazione con il gateway API/mesh è pronta (mTLS, limiti, trasmissione)?
• Strategia di versioning e compatibilità approvata?
• Dashboard/alert e test playbook per i picchi del match-day sono pronti?

16) Mini playbook (Game Days)

Partita di punta: raddoppiare la RPS lave-fide, stimare p99 e perdere messaggi (striam).
Il provider fallisce: la caduta dell'upstream - CB/outlier deve essere disattivata, il fronte deve essere degradato verso l'ultimo snap.
Regress gateway - Disattiva la trasmissione gRPC↔REST - Assicurarsi che fallback (WS/SSE) funzioni.
Ritardi di rete/WAN - Alzare artificialmente RTT per controllare l'adattamento dei timeout e backoff.
Corpi grandi (KYC) - Controlla i limiti/scarica multipla, riassume.

17) Riepilogo

All'interno del cluster, il gRPC è un default per la produttività, i contratti rigorosi e lo streaming.
Nel perimetro: REST (e WS/SSE per real-time UI) - default per l'ampia compatibilità.
Cuciamo i mondi attraverso il gateway API (trascoding, limiti, autenticazione) e il servizio mesh (mTLS, regole di traffico).
Il successo è in un'architettura mista con una netta distinzione: streaming/bassa latitudine all'interno, comfort e versatilità all'esterno.