gRPC vs REST в iGaming

1) Контекст iGaming: зачем вообще выбирать протокол

• реальное время: фиды коэффициентов, лайв-ставки, стриминг статусов купона/матча, лимиты игрока, мгновенные блокировки;
• транзакции: депозит/вывод, расчет ставок, бонусы, KYC/AML, тикеты в поддержку;
• партнерские/B2B интеграции: провайдеры игр, платежные шлюзы, аффилиаты, регуляторы.

От протокола зависят 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).
Строгие контракты между командами и версиями (Protobuf с backward-compat).

REST — сильные стороны

Публичные и партнерские API: простая интеграция (curl/Postman), партнеры без gRPC-стека.
Браузерный фронт: нативно, без прокси; поддержка кэша/ETag/304/CDN.
Долгоживущие ресурсы: каталоги игр, профили, отчеты, конфигурации.
Регуляторные выгрузки: JSON/CSV-совместимость без шлюзов.

4) Латентность и пропускная способность

gRPC экономнее по размеру полезной нагрузки (Protobuf) и затратам на сериализацию/десериализацию, выигрывает на коротких и частых вызовах.
REST/JSON добавляет 30–200% к полезной нагрузке, но выигрывает за счет кеширования и CDN на публичных GET.

Рекомендация: внутри DC/межсервисно — gRPC по умолчанию; наружу — REST, кроме реального времени.

5) Реальное время: лайв-ставки и котировки

• gRPC server streaming / bidi: постоянный поток для обновлений, backpressure, контроль окна.
• gRPC-Web (через Envoy) для браузера, если нужен бинарный протокол на фронте.
• WebSocket/SSE + REST: когда экосистема gRPC-Web не подходит или нужен чистый браузер без прокси.

Паттерн: внутри — gRPC стримы от котировщика к API-шлюзу/edge; наружу — WebSocket/SSE для фронта, REST для CRUD.

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 — метаданные.
Подписи/HMAC: чаще в REST-интеграциях B2B.
PII/логирование: бинарные payload gRPC сложнее случайно «пролить» в логи, но используйте маскировку в любом случае.
Регуляторы часто требуют человеческие выгрузки — REST/JSON удобнее.

8) Наблюдаемость и эксплуатация

Оба формата прекрасно работают c OpenTelemetry: `traceparent` (REST) / gRPC-интерсепторы.
gRPC дает богатые статусы/трейлеры; REST — привычные коды HTTP и прослойки CDN/WAF.
На шлюзе: rate limiting/quota, circuit breaker, outlier detection, fault injection — одинаково доступны (Envoy/Kong/NGINX/Traefik).

9) Совместимость и фронт

Чистый браузер не говорит gRPC из коробки → gRPC-Web или REST/WS/SSE.
Мобильные клиенты (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, политика трафика).
Успех — в смешанной архитектуре с четким разграничением: стриминг/низкая латентность внутри, удобство и универсальность снаружи.