gRPC vs REST в iGaming

1) iGaming context: why choose a protocol at all

• real time: odds feeds, live bets, streaming coupon/match statuses, player limits, instant locks;
• transactions: deposit/withdrawal, calculation of rates, bonuses, KYC/AML, tickets in support;
• partner/B2B integrations: game providers, payment gateways, affiliates, regulators.

P99 latency, stability under peaks (matches, finals), ease of integration and cost of operation depend on the protocol.

2) Brief: what is REST and gRPC

REST/HTTP/JSON: human-readable, universal. Works great with browsers/mobile SDKs, cached CDN, easy to debug.
gRPC (HTTP/2 + Protobuf): binary contracts, customer autogeneration, uni/bi-directional streaming, multiplexing, strict schemes. Service-to-service over the network is his element.

3) Where appropriate in iGaming

gRPC - Strengths

Live feeds and tracking: stream coefficients, match events, limits (server streaming/bidi).
Internal microservices: risk engine, quotation, anti-fraud scoring, balance/wallet - p99/CPU requirements.
Large RPS turnover with short messages (low price per byte, small GC-pressure).
Strict contracts between teams and versions (Protobuf with backward-compat).

REST - Strengths

Public and partner APIs: simple integration (curl/Postman), partners without gRPC stack.
Browser front: native, no proxy; / ETag/304/CDN cache support.
Long-lived resources: game catalogs, profiles, reports, configurations.
Regulatory uploads: JSON/CSV compatibility without gateways.

4) Latency and throughput

gRPC is more economical in terms of payload size (Protobuf) and serialization/deserialization costs, and benefits from short and frequent calls.
REST/JSON adds 30-200% to the payload, but benefits from caching and CDN on public GETs.

Recommendation: inside DC/inter-service - gRPC by default; outside - REST, except real time.

5) Real time: live rates and quotes

• gRPC server streaming/bidi: constant stream for updates, backpressure, window control.
• gRPC-Web (via Envoy) for the browser if you need a binary protocol at the front.
• WebSocket/SSE + REST: when the gRPC-Web ecosystem is not suitable or you need a clean browser without a proxy.

Pattern: inside - gRPC streams from the quote to the API gateway/edge; outward - WebSocket/SSE for front, REST for CRUD.

6) Idempotence, order and delivery guarantees

REST: 'Idempotency-Key' for POST on gateway, re-feed on timeout; key - in Redis/DB with TTL.
gRPC: client/balancer level retrays + idempotent methods ('retriable _ status _ codes') and sequence/versioning in streaming messages.
To calculate rates, use Inbox/Outbox + UPSERT on a bruise (see articles on deduplication and order) - the protocol itself does not guarantee a business effect.

7) Safety and compliance

Transport: TLS/mTLS in both mesh and edge; in gRPC it is easier to keep mTLS (SPIFFE/SPIRE) everywhere.
Authentication: both options support OAuth2/OIDC (JWT in 'Authorization: Bearer'), for gRPC - metadata.
Signatures/NMAS: more common in B2B REST integrations.
PII/logging: binary payload gRPCs are more difficult to accidentally "spill" into logs, but use disguise anyway.
Regulators often require human offloads - REST/JSON is more convenient.

8) Observability and operation

Both formats work great with OpenTelemetry: 'traceparent' (REST )/gRPC interseptors.
gRPC gives rich statuses/trailers; REST - familiar HTTP codes and CDN/WAF layers.
On the gateway: rate limiting/quota, circuit breaker, outlier detection, fault injection - equally available (Envoy/Kong/NGINX/Traefik).

9) Compatibility and front

A clean browser does not speak gRPC out of the box → gRPC-Web or REST/WS/SSE.
Mobile clients (iOS/Android) - gRPC clients are available, but SDK size and store policy sometimes push to REST.

10) Mixed Perimeter Architectural Patterns

10. 1 Double façade strategy

Inside (east-west): gRPC.
Outward (north-south): REST + WS/SSE.
Transcoding to edge (Envoy): one backend, two 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

→ Envoy Browser (gRPC-Web) → gRPC service. Convenient for live widgets and admin UIs.

11) Contracts and API Evolution

Protobuf (gRPC)

Only expand messages (add fields with new tags), do not change semantics and 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 by path '/v1 ', new fields are only optional.

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: What to Choose

13) Production nuances

Timeouts/Retreats

gRPC: 'per _ try _ timeout', limit 'max _ attempts', retrays only for idempotent RPCs.
REST: exponential backoff, jitter, 429/5xx policies on gateway.

Body/Method Constraint

REST: request size limits, 'Content-Type' validation.
gRPC: message size limits, flow control.

Caching

REST: `Cache-Control`, `ETag`.
gRPC: cache at the application/gateway level (for unary), for streams - snapshots/slices.

Observability

Mandatory: correlation log (request id), spans, route/method error metrics, p50/p95/p99 distribution.

14) Anti-patterns

"Rewrite everything on gRPC" and try to give to the front directly - without gRPC-Web/proxy, this will break the browser.
Public web endpoints are only gRPCs - partners will fall off.
Stream live feeds through REST polling - network overload/backend and slow quotes.
Retract non-idempotent transactions (rate creation/payment) at customer level.
Rely on physical time for event order instead of/sequence versions.

15) Protocol selection checklist

• Realtime or CRUD/partner traffic?
• Browser/Partner or Microservices/Mobile SDK Customers?
• Require streaming (server/bidi)?
• Need CDNs/caches on the perimeter?
• What are the p99 SLOs and error budget?
• Is there a regulator requirement for reporting formats (JSON/CSV)?
• Idempotency and deduplication plan defined?
• Integration with API gateway/mesh ready (mTLS, limits, translation)?
• Is the versioning and compatibility strategy approved?
• Are dashboards/alerts and test playbooks for match-day peaks ready?

16) Mini Playbooks (Game Days)

Match peak: double RPS live feeds → evaluate p99 and message loss (streams).
Provider failure: upstream fall - CB/outlier must be eliminated, the front must degrade to the last snapshot.
Gateway regress - Disable gRPC↔REST translation - Verify that the fallback (WS/SSE) is working.
Network delays/WAN: artificially raise RTT → check the adaptation of timeouts and backoff.
Large Bodies (KYC): check limits/multiple downloads, summarize.

17) Totals

Inside the cluster: gRPC - default for performance, strict contracts and streaming.
On the perimeter: REST (and WS/SSE for real-time UI) - default for broad compatibility.
Stitching worlds through an API gateway (transcoding, limits, authentication) and service mesh (mTLS, traffic policy).
Success - in a mixed architecture with a clear distinction: streaming/low latency inside, convenience and versatility on the outside.