gRPC vs REST в iGaming

1) iGaming bağlamı: neden bir protokol seçmelisiniz

• gerçek zamanlı: oran beslemeleri, canlı bahisler, akış kuponu/maç durumları, oyuncu limitleri, anlık kilitler;
• İşlemler: para yatırma/çekme, oranların hesaplanması, bonuslar, KYC/AML, destek biletleri;
• partner/B2B entegrasyonları: oyun sağlayıcıları, ödeme ağ geçitleri, bağlı kuruluşlar, düzenleyiciler.

P99 gecikme süresi, zirveler altında istikrar (maçlar, finaller), entegrasyon kolaylığı ve işlem maliyeti protokole bağlıdır.

2) Kısa: REST ve gRPC nedir

REST/HTTP/JSON: insan tarafından okunabilir, evrensel. Tarayıcılar/mobil SDK'lar, önbelleğe alınmış CDN'ler, hata ayıklaması kolay ile harika çalışır.
gRPC (HTTP/2 + Protobuf): ikili sözleşmeler, müşteri otojenerasyonu, uni/çift yönlü akış, çoklama, katı şemalar. Ağ üzerinden servis hizmeti onun öğesidir.

3) iGaming'de uygun olan yerlerde

gRPC - Güçlü Yönler

Canlı yayınlar ve izleme: akış katsayıları, eşleşme olayları, limitler (sunucu akışı/bidi).
Dahili mikro hizmetler: risk motoru, teklif, sahtekarlık karşıtı puanlama, denge/cüzdan - p99/CPU gereksinimleri.
Kısa mesajlarla büyük RPS cirosu (bayt başına düşük fiyat, küçük GC basıncı).
Takımlar ve versiyonlar arasında sıkı sözleşmeler (geriye dönük compat ile Protobuf).

REST - Güçlü yönler

Genel ve ortak API'ler: basit entegrasyon (curl/Postman), gRPC yığını olmayan ortaklar.
Tarayıcı önü: yerel, proxy yok ;/ ETag/304/CDN önbellek desteği.
Uzun ömürlü kaynaklar: oyun katalogları, profiller, raporlar, yapılandırmalar.
Düzenleyici yüklemeler: Ağ geçitleri olmadan JSON/CSV uyumluluğu.

4) Gecikme ve iş hacmi

gRPC, yük boyutu (Protobuf) ve serileştirme/çölleştirme maliyetleri açısından daha ekonomiktir ve kısa ve sık çağrılardan yararlanır.
REST/JSON, yüke %30-200 ekler, ancak genel GET'lerde önbelleğe alma ve CDN'den yararlanır.

Öneri: DC/inter-service içinde - varsayılan olarak gRPC; Dışarıda - REST, gerçek zamanlı hariç.

5) Gerçek zamanlı: canlı oranlar ve alıntılar

• gRPC sunucu akışı/bidi: güncellemeler için sürekli akış, geri basınç, pencere kontrolü.
• Önünüzde ikili bir protokole ihtiyacınız varsa, tarayıcı için gRPC-Web (Elçi aracılığıyla).
• WebSocket/SSE + REST: gRPC-Web ekosistemi uygun olmadığında veya proxy olmadan temiz bir tarayıcıya ihtiyacınız olduğunda.

Desen: içeride - gRPC tekliften API ağ geçidine/kenarına akar; Dışa doğru - Ön taraf için WebSocket/SSE, CRUD için REST.

6) Idempotence, sipariş ve teslimat garantileri

REST: Ağ geçidinde POST için 'Idempotency-Key', zaman aşımında yeniden besleme; Anahtar - TTL ile Redis/DB'de.
gRPC: client/balancer level retrays + idempotent methods ('retriable _ status _ codes') and sequence/versioning in streaming messages.
Oranları hesaplamak için, bir çürük üzerinde Inbox/Outbox + UPPERT kullanın (veri tekilleştirme ve sipariş ile ilgili makalelere bakın) - protokolün kendisi bir iş etkisi garanti etmez.

7) Güvenlik ve uyumluluk

Taşıma: Hem kafes hem de kenarda TLS/mTLS; gRPC'de mTLS'yi (SPIFFE/SPIRE) her yerde tutmak daha kolaydır.
Kimlik doğrulama: Her iki seçenek de OAuth2/OIDC ('Authorization: Bearer' içindeki JWT), gRPC için - meta verileri destekler.
İmzalar/NMAS: B2B REST entegrasyonlarında daha yaygındır.
PII/logging: binary payload gRPC'lerin yanlışlıkla günlüklere "dökülmesi'daha zordur, ancak yine de kılık değiştirin.
Düzenleyiciler genellikle insan boşaltma gerektirir - REST/JSON daha uygundur.

8) Gözlemlenebilirlik ve çalışma

Her iki format da OpenTelemetry ile harika çalışır: 'Traceparent' (REST )/gRPC interseptörleri.
gRPC zengin durumlar/römorklar verir; REST - tanıdık HTTP kodları ve CDN/WAF katmanları.
Ağ geçidinde: hız sınırlayıcı/kota, devre kesici, aykırı tespit, hata enjeksiyonu - eşit olarak kullanılabilir (Elçi/Kong/NGINX/Traefik).

9) Uyumluluk ve ön

Temiz bir tarayıcı gRPC'yi kutudan çıkarmaz - gRPC-Web veya REST/WS/SSE.
Mobil istemciler (iOS/Android) - gRPC istemcileri mevcuttur, ancak SDK boyutu ve mağaza politikası bazen REST'e iter.

10) Karışık Çevre Mimari Desenler

10. 1 Çift cephe stratejisi

İç (doğu-batı): gRPC.
Dışa doğru (kuzey-güney): REST + WS/SSE.
Uç uca dönüştürme (Elçi): bir arka uç, iki müşteri.

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

Elçi Tarayıcı (gRPC-Web) - gRPC hizmeti. Canlı widget'lar ve yönetici UI'leri için uygundur.

11) Sözleşmeler ve API Evrimi

Protobuf (gRPC)

Yalnızca mesajları genişletin (yeni etiketlerle alanlar ekleyin), semantik ve türleri değiştirmeyin.

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 'yoluna göre sürüm oluşturma, yeni alanlar yalnızca isteğe bağlıdır.

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 Kılıfları: Ne Seçilmeli

13) Üretim nüansları

Zaman Aşımları/Geri Çekilmeler

gRPC: 'per _ try _ timeout', limit 'max _ girişimleri', sadece idempotent RPC'ler için retrays.
REST: üstel geri dönüş, titreme, ağ geçidinde 429/5xx politikaları.

Gövde/yöntem kısıtlaması

REST: request size limits, 'Content-Type' doğrulaması.
gRPC: mesaj boyutu sınırları, akış kontrolü.

Önbelleğe alma

REST: 'Cache-Control', 'ETag'.
gRPC: uygulama/ağ geçidi düzeyinde önbellek (unary için), akışlar için - anlık görüntüler/dilimler.

Gözlemlenebilirlik

Zorunlu: korelasyon günlüğü (istek kimliği), açıklıklar, rota/yöntem hatası metrikleri, p50/p95/p99 dağılımı.

14) Anti-desenler

"gRPC'deki her şeyi yeniden yazın've doğrudan öne vermeye çalışın - gRPC-Web/proxy olmadan, bu tarayıcıyı kıracaktır.
Genel web uç noktaları sadece gRPC'lerdir - ortaklar düşecektir.
REST yoklaması aracılığıyla canlı yayınları yayınlayın - ağ aşırı yüklemesi/arka uç ve yavaş tırnak işaretleri.
Idempotent olmayan işlemleri (oran oluşturma/ödeme) müşteri düzeyinde geri çekin.
/ sequence sürümleri yerine olay sırası için fiziksel zamana güvenin.

15) Protokol seçim kontrol listesi

• Gerçek zamanlı veya CRUD/ortak trafik?
• Tarayıcı/İş Ortağı veya Mikro Hizmetler/Mobil SDK Müşterileri?
• Akış gerektirir (sunucu/bidi)?
• Çevrede CDN'lere/önbelleklere mi ihtiyacınız var?
• p99 SLO'lar ve hata bütçesi nedir?
• Raporlama formatları (JSON/CSV) için bir düzenleyici gerekliliği var mı?
• Idempotency ve veri tekilleştirme planı tanımlandı mı?
• API ağ geçidi/mesh ile entegrasyon hazır (mTLS, limitler, çeviri)?
• Sürüm oluşturma ve uyumluluk stratejisi onaylandı mı?
• Maç günü zirveleri için gösterge panoları/uyarılar ve test oyun kitapları hazır mı?

16) Mini Playbooks (Oyun Günleri)

Zirveyi eşleştir: Çift RPS canlı yayınları - p99 ve mesaj kaybını (akışları) değerlendirin.
Sağlayıcı hatası: upstream fall - CB/outlier ortadan kaldırılmalı, ön kısım son anlık görüntüye indirgenmelidir.
Ağ Geçidi gerilemesi - gRPC↔REST çevirisini devre dışı bırak - Geri dönüşün (WS/SSE) çalıştığını doğrulayın.
Ağ gecikmeleri/WAN: yapay olarak RTT'yi yükseltin - zaman aşımı ve geri çekilme uyarlamasını kontrol edin.
Büyük Gövdeler (KYC): sınırları kontrol edin/birden fazla indirme yapın, özetleyin.

17) Toplam

Kümenin içinde: gRPC - performans, katı sözleşmeler ve akış için varsayılan.
Çevre: REST (ve gerçek zamanlı UI için WS/SSE) - geniş uyumluluk için varsayılan.
Bir API ağ geçidi (kod dönüştürme, sınırlar, kimlik doğrulama) ve servis ağı (mTLS, trafik ilkesi) aracılığıyla dünyaları birleştirme.
Başarı - net bir ayrımla karışık bir mimaride: içeride akış/düşük gecikme süresi, dışarıda rahatlık ve çok yönlülük.