gRPC बनाम REST в iGaming

1) iGaming संदर्भ: एक प्रोटोकॉल क्यों चुनें

• वास्तविक समय: ऑड्स फ़ीड, लाइव दांव, स्ट्रीमिंग कूपन/मैच स्टेटस, खिलाड़ी सीमा, त्वरित ताले;
• लेनदेन: जमा/निकासी, दरों की गणना, बोनस, केवाईसी/एएमएल, समर्थन में टिकट;
• partner/B2B एकीकरण: खेल प्रदाता, भुगतान द्वार, सहयोगी, नियामक।

P99 विलंबता, चोटियों (मैच, फाइनल) के तहत स्थिरता, एकीकरण में आसानी और संचालन की लागत प्रोटोकॉल पर निर्भर करती है।

2) संक्षिप्त: REST और gRPC क्या है

REST/HTTP/JSON: मानव-पढ़ने योग्य, सार्वभौमिक। ब्राउज़र/मोबाइल एसडीके के साथ शानदार काम करता है, सीडीएन को कैश करता है, डिबग करना आसान है।

gRPC (HTTP/2 + Protobuf): द्विआधारी अनुबंध, ग्राहक ऑटोजनरेशन, uni/bi-directional स्ट्रीमिंग, मल्टीप्लेक्सिंग, सख्त योजनाएं। नेटवर्क पर सेवा-से-सेवा उसका तत्व है।

3) iGaming में उपयुक्त कहाँ

जीआरपीसी - ताकत

लाइव फीड और ट्रैकिंग: स्ट्रीम गुणांक, मैच इवेंट्स, लिमिट (सर्वर स्ट्रीमिंग/बीडी)।

आंतरिक माइक्रोसर्विसेज: जोखिम इंजन, उद्धरण, एंटी-फ्रॉड स्कोरिंग, बैलेंस/वॉलेट - p99/CPU आवश्यकताएं।

छोटे संदेशों के साथ बड़े आरपीएस कारोबार (प्रति बाइट कम कीमत, छोटे जीसी-दबाव)।

टीमों और संस्करणों के बीच सख्त अनुबंध (बैकवर्ड-कॉम्पैट के साथ प्रोटोबुफ)।

विश्राम - शक्तियाँ

सार्वजनिक और साथी एपीआई: सरल एकीकरण (कर्ल/पोस्टमैन), जीआरपीसी स्टैक के बिना भागीदार।

ब्राउज़र फ्रंट: देशी, कोई प्रॉक्सी नहीं ;/ ETag/304/CDN कैश समर्थन।

लंबे समय तक जीवित संसाधन: गेम कैटलॉग, प्रोफाइल, रिपोर्ट, कॉन्फ़िगरेशन।

नियामक अपलोड: द्वार के बिना JSON/CSV संगतता।

4) विलंबता और थ्रूपुट

जीआरपीसी पेलोड आकार (प्रोटोबुफ) और क्रमबद्धता/मरुस्थलीकरण लागत के संदर्भ में अधिक किफायती है, और छोटी और बार-बार कॉल से लाभ होता है।

REST/JSON पेलोड में 30-200% जोड़ ता है, लेकिन सार्वजनिक GETs पर कैशिंग और CDN से लाभ।

सिफारिश: डीसी/इंटर-सर्विस - जीआरपीसी के अंदर डिफ़ॉल्ट रूप से; बाहर - REST, वास्तविक समय को छोड़ कर।

5) वास्तविक समय: लाइव दरें और उद्धरण

• gRPC सर्वर स्ट्रीमिंग/बिडी: अद्यतन, बैकप्रेशर, विंडो नियंत्रण के लिए निरंतर स्ट्रीम।
• यदि आपको सामने वाले द्विआधारी प्रोटोकॉल की आवश्यकता है, तो ब्राउज़र के लिए gRPC-वेब (दूत के माध्यम से)।
• WebSocket/SSE + REST: जब gRPC-वेब पारिस्थितिकी तंत्र उपयुक्त नहीं होता है या आपको बिना प्रॉक्सी के साफ ब्राउज़र की आवश्यकता होती है।

पैटर्न: अंदर - जीआरपीसी उद्धरण से एपीआई प्रवेश द्वार/किनारे तक धाराएँ; बाहर - सामने के लिए वेबसॉकेट/एसएसई, CRUD के लिए REST।

6) आइडेम्पोटेंस, ऑर्डर और डिलीवरी गारंटी

REST: गेटवे पर POST के लिए 'आइडेम्पोटेंसी-की', टाइमआउट पर फिर से फ़ीड; कुंजी - टीटीएल के साथ Redis/DB में।

gRPC: स्ट्रीमिंग संदेशों में क्लाइंट/बैलेंसर लेवल रिट्रेज + आइडेम्पोटेंट तरीके ('रिट्रीबल _ स्टेटस _ कोड') और सीक्वेंस/वर्शनिंग।

दरों की गणना करने के लिए, एक चोट पर इनबॉक्स/आउटबॉक्स + UPSERT का उपयोग करें (डीडुप्लीकेशन और ऑर्डर पर लेख देखें) - प्रोटोकॉल स्वयं व्यावसायिक प्रभाव की गारंटी नहीं देता है।

7) सुरक्षा और अनुपालन

परिवहन: जाल और किनारे दोनों में टीएलएस/एमटीएलएस; gRPC में हर जगह mTLS (SPIFFE/SPIRE) रखना आसान है।

प्रमाणीकरण: दोनों विकल्प gRPC - मेटाडेटा के लिए OAuth2/OIDC ('प्राधिकरण: वाहक' में JWT) समर्थन करते हैं।

हस्ताक्षर/NMAS: B2B REST एकीकरण में अधिक सामान्य।

पीआईआई/लॉगिंग: बाइनरी पेलोड जीआरपीसी को गलती से लॉग में "स्पिल" करना अधिक कठिन है, लेकिन वैसे भी भेस का उपयोग करें।

नियामकों को अक्सर मानव ऑफलोड की आवश्यकता होती है - REST/JSON अधिक सुविधाजनक है।

8) अवलोकन और संचालन

दोनों प्रारूप OpenTelemetry के साथ बहुत अच्छा काम करते हैं: 'traceparent' (REST )/gRPC चौराहे।

gRPC समृद्ध स्टेटस/ट्रेलर देता है; REST - परिचित HTTP कोड और CDN/WAF परतें।

प्रवेश द्वार पर: दर सीमित/कोटा, सर्किट ब्रेकर, बाहरी पहचान, गलती इंजेक्शन - समान रूप से उपलब्ध (दूत/कोंग/NGINX/Traefik)।

9) संगतता और मोर्चा

एक साफ ब्राउज़र बॉक्स से gRPC नहीं बोलता है → gRPC-Web या REST/WS/SSE।

मोबाइल क्लाइंट (iOS/Android) - gRPC क्लाइंट उपलब्ध हैं, लेकिन SDK आकार और स्टोर नीति कभी-कभी REST पर धकेलती है।

10) मिश्रित परिधि वास्तुशिल्प पैटर्न

10. 1 डबल अग्रभाग रणनीति

अंदर (पूर्व-पश्चिम): gRPC।

आउटवर्ड (उत्तर-दक्षिण): REST + WS/SSE।

ट्रांसकोडिंग टू एज (दूत): एक बैकेंड, दो क्लाइंट।

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 जीआरपीसी-वेब

→ दूत ब्राउज़र (जीआरपीसी-वेब) → जीआरपीसी सेवा। लाइव विजेट और व्यवस्थापक यूआई के लिए सुविधाजनक।

11) अनुबंध और एपीआई एवोल्यूशन

प्रोटोबुफ (जीआरपीसी)

केवल संदेशों का विस्तार करें (नए टैग के साथ फ़ील्ड जोड़ें), शब्दार्थ और प्रकार न बदलें।

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 _ perses' को सीमित करें, केवल idempotent RPC के लिए पुनः प्रयास करता है।

REST: गेटवे पर घातीय बैकऑफ, जिटर, 429/5xx नीतियां।

शरीर/विधि प्रतिबंध

REST: अनुरोध आकार सीमा, 'सामग्री-प्रकार' सत्यापन.

gRPC: संदेश आकार सीमा, प्रवाह नियंत्रण।

कैचिंग

REST: 'कैश-कंट्रोल', 'ETag'।

gRPC: स्ट्रीम - स्नैपशॉट/स्लाइस के लिए एप्लिकेशन/गेटवे स्तर (एकात्मक के लिए) पर कैश।

अवलोकन क्षमता

अनिवार्य: सहसंबंध लॉग (अनुरोध आईडी), स्पैन, रूट/मेथड त्रुटि मेट्रिक्स, p50/p95/p99 वितरण।

14) एंटी-पैटर्न

"जीआरपीसी पर सब कुछ फिर से लिखें" और सीधे सामने को देने की कोशिश करें - जीआरपीसी-वेब/प्रॉक्सी के बिना, यह ब्राउज़र को तोड़ देगा।

सार्वजनिक वेब समापन बिंदु केवल जीआरपीसी हैं - साझेदार गिर जाएंगे।

REST मतदान के माध्यम से स्ट्रीम लाइव फीड - नेटवर्क ओवरलोड/बैकएंड और धीमा उद्धरण।

ग्राहक स्तर पर गैर-आइडेम्पोटेंट लेनदेन (दर निर्माण/भुगतान) को वापस लेना।

घटना क्रम के बदले/अनुक्रम संस्करणों के लिए भौतिक समय पर भरोसा करें।

15) प्रोटोकॉल चयन चेकलिस्ट

• Realtime या CRUD/साथी यातायात?
• ब्राउज़र/पार्टनर या माइक्रोसर्विसेस/मोबाइल एसडीके ग्राहक?
• स्ट्रीमिंग (सर्वर/बीडी) की आवश्यकता है?
• परिधि पर सीडीएन/कैश की आवश्यकता है?
• p99 SLO और त्रुटि बजट क्या हैं?
• क्या रिपोर्टिंग प्रारूपों (JSON/CSV) के लिए नियामक की आवश्यकता है?
• पहचान और कमी योजना परिभाषित?
• एपीआई गेटवे/मेष तैयार (एमटीएलएस, सीमा, अनुवाद) के साथ एकीकरण?
• क्या वर्शनिंग और संगतता रणनीति को मंजूरी दी गई है?
• क्या मैच-डे चोटियों के लिए डैशबोर्ड/अलर्ट और टेस्ट प्लेबुक तैयार हैं?

16) मिनी प्लेबुक (गेम डेज़)

मैच शिखर: डबल आरपीएस लाइव फीड - p99 और संदेश हानि (धाराएं) का मूल्यांकन करें।

प्रदाता विफलता: अपस्ट्रीम फॉल - सीबी/आउटलियर को समाप्त किया जाना चाहिए, सामने को अंतिम स्नैपशॉट के लिए नीचा दिखाना चाहिए।

गेटवे रीग्रेस - अक्षम gRPC↔REST अनुवाद - सत्यापित करें कि फॉलबैक (WS/SSE) काम कर रहा है।

नेटवर्क देरी/वैन: कृत्रिम रूप से RTT उठाएं - टाइमआउट और बैकऑफ के अनुकूलन की जांच करें।

बड़े निकाय (KYC): सीमा/एकाधिक डाउनलोड की जाँच करें, संक्षेप में करें।

17) कुल

क्लस्टर के अंदर: gRPC - निष्पादन के लिए डिफ़ॉल्ट, सख्त अनुबंध और स्ट्रीमिंग।

परिधि पर: REST (और वास्तविक समय UI के लिए WS/SSE) - व्यापक संगतता के लिए डिफ़ॉल्ट।

एपीआई प्रवेश द्वार (ट्रांसकोडिंग, सीमा, प्रमाणीकरण) और सेवा जाल (एमटीएलएस, यातायात नीति) के माध्यम से दुनिया को सिलाई।

सफलता - एक स्पष्ट अंतर के साथ एक मिश्रित वास्तुकला में: स्ट्रीमिंग/कम विलंबता अंदर, सुविधा और बाहर पर बहुमुखी प्रतिभा।