gRPC vs REST в iGaming

1) Contexte iGaming : pourquoi choisir le protocole en général

• temps réel : fids de ratios, taux de vie, status streaming coupon/match, limites du joueur, blocages instantanés ;
• transactions : dépôt/retrait, calcul des taux, bonus, KYC/AML, tickets à l'appui ;
• partenaires/B2B intégration : fournisseurs de jeux, passerelles de paiement, affiliations, régulateurs.

Le protocole dépend de la p99-latence, de la stabilité sous les pics (matchs, finales), de la commodité des intégrations et du coût d'exploitation.

2) Bref : qu'est-ce que REST et gRPC

REST/HTTP/JSON : humain, universel. Fonctionne parfaitement avec les navigateurs/SDK mobile, cache CDN, facile à débiter.
gRPC (HTTP/2 + Protobuf) : contrats binaires, production automatique de clients, streaming uni/bi-directif, multiplexage, schémas rigoureux. Le service-k-service sur le réseau est son élément.

3) Le cas échéant dans iGaming

gRPC - points forts

Live Fides et tracking : streaming de coefficients, événements de match, limites (serveur streaming/bidi).
Microservices internes : moteur à risque, cotateur, scoring antifrode, balance/portefeuille - exigences de p99/CPU.
Grand tour de RPS avec messages courts (faible prix d'octet, petite pression GC).
Contrats stricts entre les équipes et les versions (Protobuf avec backward-compat).

REST - points forts

API publiques et partenaires : intégration simple (curl/Postman), partenaires sans pile gRPC.
Front du navigateur : natif, sans proxy ; support cache/ETag/304/CDN.
Ressources à longue durée de vie : catalogues de jeux, profils, rapports, configurations.
Déchargement réglementaire : compatibilité JSON/CSV sans passerelles.

4) Latence et bande passante

Le gRPC est plus économique en termes de taille de charge utile (Protobuf) et de coûts de sérialisation/désérialisation, gagne sur les appels courts et fréquents.
REST/JSON ajoute de 30 à 200 % à la charge utile, mais gagne grâce au cache et au CDN sur les GET publics.

Recommandation : au sein de DC/interservices - gRPC par défaut ; dehors - REST, sauf en temps réel.

5) Temps réel : Taux de vie et devis

• gRPC server streaming/bidi : flux constant pour les mises à jour, backpressure, contrôle de fenêtre.
• gRPC-Web (via Envoy) pour le navigateur si vous avez besoin d'un protocole binaire sur le front.
• WebSocket/SSE + REST : lorsque l'écosystème gRPC-Web ne convient pas ou a besoin d'un navigateur propre sans proxy.

Patterns : à l'intérieur - gRPC strips du coteur à la passerelle API/edge ; out - WebSocket/SSE pour le front, REST pour le CRUD.

6) Idempotence, ordre et garanties de livraison

REST : 'Idempotency-Key' pour POST sur la passerelle, réapprovisionnement en temporisation ; la clé est dans Redis/OBD c TTL.
gRPC : retraits au niveau client/équilibreur + méthodes idempotentes ('retriable _ status _ codes') et sequence/versioning dans les messages de streaming.
Pour calculer les taux, utilisez Inbox/Outbox + UPSERT sur le bleu (voir les articles sur la déduplication et l'ordre) - le protocole lui-même ne garantit pas l'effet professionnel.

7) Sécurité et conformité

Transport : TLS/mTLS en mesh et en edge ; en gRPC, il est plus facile de garder mTLS partout (SPIFFE/SPIRE).
Authentification : Les deux options prennent en charge les OAuth2/OIDC (JWT dans 'Autorisation : Bearer'), pour gRPC - métadonnées.
Signatures/NMAS : plus souvent dans les intégrations REST B2B.
PII/loging : les payload binaires gRPC sont plus difficiles à « verser » accidentellement dans les logs, mais utilisez le masquage de toute façon.
Les régulateurs exigent souvent un déchargement humain - REST/JSON est plus pratique.

8) Observabilité et exploitation

Les deux formats fonctionnent parfaitement avec les intersepteurs OpenTelemetry : « traceparent » (REST )/gRPC.
gRPC donne des statuts/remorques riches ; REST - codes HTTP habituels et intercalaires CDN/WAF.
Sur la passerelle : rate limiting/quota, circuit breaker, outlier detection, fault injection - également disponible (Envoy/Kong/NGINX/Traefik).

9) Compatibilité et front

Un navigateur propre ne dit pas gRPC de la boîte → gRPC-Web ou REST/WS/SSE.
Clients mobiles (iOS/Android) - Les clients gRPC sont disponibles, mais la taille du SDK et la politique de store poussent parfois vers REST.

10) Modèles architecturaux de périmètre mixte

10. 1 Stratégie « double façade »

À l'intérieur (est-ouest) : gRPC.
Vers l'extérieur (nord-sud) : REST + WS/SSE.
Transcoding sur edge (Envoy) : un backend, deux clients.

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

Navigateur → Envoy (gRPC-Web) → service gRPC. Pratique pour les widgets live et les UI admin.

11) Contrats et évolution de l'API

Protobuf (gRPC)

N'étendez que les messages (ajoutez des champs avec de nouvelles étiquettes), ne changez pas la sémantique et les types.

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 sur le chemin '/v1 ', les nouveaux champs sont uniquement optionnels.

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) Case iGaming : que choisir

13) Nuances de production

Temporisation/Retrai

gRPC : 'per _ try _ timeout', limiter 'max _ attempts', retraits uniquement pour les RPC idempotent.
REST : exponentielle backoff, gitter, 429/5xx-polices sur la passerelle.

Limitation du corps/méthode

REST : limites de taille de requête, validation « Content-Type ».
gRPC : limites de taille des messages, flow control.

Cache

REST: `Cache-Control`, `ETag`.
gRPC : cache au niveau de l'application/passerelle (pour unary), pour les strimes - snapshots/tranches.

Observabilité

Sont obligatoires : journal de corrélation (request id), spans, métriques d'erreur par route/méthode, distribution p50/p95/p99.

14) Anti-modèles

« Réécrire tout sur gRPC » et essayer de donner directement au front - sans gRPC-Web/proxy cela cassera le navigateur.
Les endpoints web publics ne sont que des gRPC - les partenaires vont tomber.
Streaming Live Fids via REST-polling - surchauffe du réseau/bekend et des cotations lentes.
Rétractez les transactions non ponctuelles (création de taux/paiement) au niveau du client.
Compter sur le temps physique pour l'ordre des événements au lieu des versions/sequence.

15) Chèque-liste de sélection du protocole

• Trafic realtime ou CRUD/partenaire ?
• Clients - navigateur/partenaires ou microservices/SDK mobiles ?
• Besoin de streaming (server/bidi) ?
• Besoin de CDN/cachis sur le périmètre ?
• Quels SLO par p99 et budget des erreurs ?
• Existe-t-il des exigences réglementaires pour les formats de déclaration (JSON/CSV) ?
• Le plan d'idempotence et de dédoublement est-il défini ?
• L'intégration avec la passerelle API/mesh est-elle prête (mTLS, limites, traduction) ?
• Stratégie de versioning et d'interopérabilité approuvée ?
• Les dashboards/alertes et les playbooks de test sont-ils prêts pour le match-day ?

16) Mini-playbooks (Game Days)

Match-peak : doubler le RPS des lives → évaluer p99 et les pertes de messages (strim).
L'échec du fournisseur : la chute de l'apstream - CB/outlier doit être éliminée, le front - se dégrade vers le dernier snapshot.
Régression de la passerelle : Désactiver la diffusion de l' gRPC↔REST - assurez-vous que fallback (WS/SSE) fonctionne.
Retards réseau/WAN : Soulevez artificiellement le RTT → vérifiez l'adaptation des temporisations et du backoff.
Grands corps (KYC) : vérifier les limites/téléchargements multiples, résumer.

17) Résultats

Au sein du cluster : gRPC - défaut de performance, contrats stricts et streaming.
Sur le périmètre : REST (et WS/SSE pour real-time UI) - défaut pour une grande compatibilité.
Nous coudions les mondes via une passerelle API (transcodage, limites, authentification) et un service mesh (mTLS, politique de trafic).
Le succès est dans une architecture mixte avec une distinction claire : streaming/faible latence à l'intérieur, commodité et polyvalence à l'extérieur.