gRPC vs REST) iGaming

1) iGaming 컨텍스트: 프로토콜을 전혀 선택하지 않는 이유

iGaming 플랫폼은 동시에 제공됩니다

실시간: 배당률 피드, 라이브 베팅, 스트리밍 쿠폰/경기 상태, 플레이어 제한, 인스턴트 잠금;

거래: 예금/인출, 요금 계산, 보너스, KYC/AML, 지원 티켓;

파트너/B2B 통합: 게임 제공 업체, 결제 게이트웨이, 계열사, 규제 기관.

P99 대기 시간, 피크 하의 안정성 (일치, 최종), 통합 용이성 및 작동 비용은 프로토콜에 따라 다릅니다.

2) 간략한 설명: REST 및 gRPC

REST/TH/JSON: 사람이 읽을 수 있고 보편적입니다. 브라우저/모바일 SDK, 캐시 된 CDN과 함께 작동하며 디버깅하기 쉽습니다.
gRPC (해/2 + 프로토 타입): 이진 계약, 고객 자동 생성, 단일/양방향 스트리밍, 멀티플렉싱, 엄격한 체계. 네트워크를 통한 서비스 서비스가 그의 요소입니다.

3) iGaming에 적합한 경우

gRPC-강점

라이브 피드 및 추적: 스트림 계수, 일치 이벤트, 한계 (서버 스트리밍/비디).
내부 마이크로 서비스: 위험 엔진, 견적, 사기 방지 점수, 잔액/지갑-p99/CPU 요구 사항.
짧은 메시지가있는 큰 RPS 회전율 (바이트 당 저렴한 가격, 작은 GC 압력).
팀과 버전 간의 엄격한 계약 (이전 버전과의 프로토 타입).

REST-강점

공개 및 파트너 API: 간단한 통합 (컬/포스트 맨), gRPC 스택이없는 파트너.
브라우저 전면: 네이티브, 프록시 없음 ;/ETag/304/CNC 캐시 지원.
장기 리소스: 게임 카탈로그, 프로필, 보고서, 구성.
규제 업로드: 게이트웨이가없는 JSON/SL 호환성.

4) 대기 시간 및 처리량

gRPC는 페이로드 크기 (프로토로드) 및 직렬화/사막화 비용 측면에서보다 경제적이며 짧고 빈번한 통화의 이점이 있습니다.
REST/JSON은 페이로드에 30-200% 를 추가하지만 공개 GET의 캐싱 및 CDN의 혜택을받습니다.

추천: 내부 DC/서비스 간 - 기본적으로 gRPC; 외부-실시간을 제외한 REST.

5) 실시간: 실시간 요금 및 견적

• gRPC 서버 스트리밍/비디: 업데이트, 역압, 창 제어를위한 일정한 스트림.
• 전면에 이진 프로토콜이 필요한 경우 브라우저의 gRPC-Web (Envoy를 통해).
• WebSocket/SSE + REST: gRPC-Web 생태계가 적합하지 않거나 프록시가없는 깨끗한 브라우저가 필요한 경우.

패턴: 내부-gRPC는 견적에서 API 게이트웨이/에지로 스트리밍됩니다. 외부-전면 웹 소켓/SSE, CRUD 용 REST.

6) 이념, 주문 및 배송 보증

REST: 게이트웨이에서 POST를위한 'Idempotency-Key', 타임 아웃시 다시 피드; 키-TTL이있는 Redis/DB에서.
gRPC: 클라이언트/밸런서 레벨은 스트리밍 메시지에서 + dempotent 메소드 ('검색 가능 _ 상태 _ 코드') 및 시퀀스/버전을 재구성합니다.
요금을 계산하려면 멍에에서받은 편지함/전송 + UPSERT를 사용하십시오 (중복 및 순서에 관한 기사 참조). 프로토콜 자체가 비즈니스 효과를 보장하지는 않습니다.

7) 안전 및 준수

전송: 메쉬와 에지 모두에서 SL/mTLS; gRPC에서는 모든 곳에서 mSL (SPIFFE/SPIRE) 을 유지하는 것이 더 쉽습니다.
인증: 두 옵션 모두 gRPC-메타 데이터에 대해 OAuth2/OIDC ('Authorization: Bearer' 의 JWT) 를 지원합니다.
서명/NMAS: B2B REST 통합에서 더 일반적입니다.
PII/로깅: 이진 페이로드 gRPC는 실수로 로그에 "유출" 하기가 더 어렵지만 어쨌든 변장을 사용합니다.
레귤레이터는 종종 사람의 오프로드가 필요합니다. REST/JSON이 더 편리합니다.

8) 관찰 및 운영

두 형식 모두 OpenTelemetry에서 'traceparent' (REST )/gRPC interseptors와 잘 작동합니다.
gRPC는 풍부한 상태/트레일러를 제공합니다. REST - 친숙한 HTP 코드 및 CNC/WAF 계층.
게이트웨이에서 속도 제한/할당량, 회로 차단기, 특이 치 감지, 결함 분사-동일하게 사용 가능 (Envoy/Kong/NGINX/Traefik).

9) 호환성 및 전면

깨끗한 브라우저는 상자에서 gRPC를 말하지 않습니다 → gRPC-Web 또는 REST/WS/SSE.
모바일 클라이언트 (iOS/Android) -gRPC 클라이언트를 사용할 수 있지만 SDK 크기 및 상점 정책은 때때로 REST로 전환됩니다.

10) 혼합 경계계 건축 패턴

10. 1 더블 파사드 전략

내부 (동서): gRPC.
바깥 쪽 (남북): REST + WS/SSE.
트랜잭션 (Envoy): 백엔드 1 개, 클라이언트 2 개.

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 웹

→ 특사 브라우저 (gRPC-Web) → gRPC 서비스. 라이브 위젯 및 관리자 UI를위한 편리함.

11) 계약 및 API 진화

프로토 파이 (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 _ trides' 제한, demempotent RPC에 대해서만 배상됩니다.
REST: 게이트웨이의 지수 백오프, 지터, 429/5xx 정책.

신체/방법 제약

REST: 요청 크기 제한, '콘텐츠 유형' 검증.
gRPC: 메시지 크기 제한, 흐름 제어.

캐싱

REST: '캐시 컨트롤', 'ETag'.
gRPC: 스트림-스냅 샷/슬라이스를 위해 응용 프로그램/게이트웨이 레벨 (단일) 에 캐시하십시오.

관찰 가능

필수: 상관 로그 (요청 ID), 스팬, 경로/방법 오류 메트릭, p50/p95/p99 분포.

14) 반 패턴

"gRPC에 모든 것을 다시 작성" 하고 gRPC 웹/프록시없이 전면에 직접 제공하려고하면 브라우저가 중단됩니다.
공개 웹 엔드 포인트는 gRPC 일뿐입니다. 파트너는 떨어질 것입니다.
REST 폴링 (네트워크 과부하/백엔드 및 느린 따옴표) 을 통해 라이브 피드를 스트리밍하십시오.
고객 수준에서 비 등급 거래 (요율 생성/지불) 를 줄입니다.
/ 시퀀스 버전 대신 이벤트 순서의 실제 시간에 따라 다릅니다.

15) 프로토콜 선택 체크리스트

• 실시간 또는 CRUD/파트너 트래픽?
• 브라우저/파트너 또는 마이크로 소프트/모바일 SDK 고객?
• 스트리밍 (서버/비디) 이 필요하십니까?
• 주변에 CDNs/caches가 필요합니까?
• p99 SLO 및 오류 예산은 무엇입니까?
• 형식을보고하기위한 규제 기관 요구 사항이 있습니까 (JSON/CS)?
• 이념과 중복 계획이 정의 되었습니까?
• API 게이트웨이/메쉬 준비가 완료된 통합 (mSL, 한계, 변환)?
• 버전 및 호환성 전략이 승인되었습니까?
• 경기 당일 피크에 대한 대시 보드/알림 및 테스트 플레이 북이 준비되어 있습니까?

16) 미니 플레이 북 (게임 데이)

경기 피크: 이중 RPS 라이브 피드 → p99 및 메시지 손실 (스트림) 을 평가합니다.
공급자 고장: 업스트림 하락-CB/이상 치를 제거해야하며 전면이 마지막 스냅 샷으로 저하되어야합니다.
게이트웨이 회귀-gRPC 사용하지 않음 REST 변환-폴백 (WS/SSE) 이 작동하고 있음을 확인하십시오.
네트워크 지연/WAN: 인위적으로 RTT → 타임 아웃 및 백오프의 적응을 확인하십시오.
KYC (Large Bodies): 한계/다중 다운로드를 확인하고 요약하십시오.

17) 총계

클러스터 내부: gRPC-성능, 엄격한 계약 및 스트리밍의 기본값.
주변에서: REST (및 실시간 UI의 경우 WS/SSE) -광범위한 호환성을 위해 기본값입니다.
API 게이트웨이 (트랜스 코딩, 제한, 인증) 및 서비스 메쉬 (mSL, 트래픽 정책) 를 통한 세계 스티칭.
성공-스트리밍/낮은 대기 시간, 외부의 편의성 및 다양성과 같이 명확한 차이가있는 혼합 아키텍처에서.