GH GambleHub

माइक्रोसर्विस वास्तुकला

1) iGaming में microservices क्यों

परिवर्तन की गति: टीम सुविधाओं (भुगतान, सामग्री, जोखिम, टूर्नामेंट) की स्वतंत्र रिलीज

विश्वसनीयता: एक सेवा की विफलता पूरे उत्पाद (विफलता सीमा) को नीचे नहीं लाती है।

स्केल: "हॉट" डोमेन (बटुआ, लॉबी, धाराएँ) का क्षैतिज स्केल।

अनुपालन: क्षेत्र/क्षेत्राधिकार द्वारा डेटा का अलगाव।

जब इसके लायक नहीं है: एक छोटी टीम/वॉल्यूम, कोई DevOps प्रथाएं, परीक्षणों का कमजोर स्वचालन - तो एक मॉड्यूलर मोनोलिथ बेहतर है।

2) डोमेन, बॉर्डर और टीमें (डीडीडी + टीम टोपोलॉजी)

डोमेन आकृति: खाता/प्रोफ़ाइल, सीसीएम/अनुपालन, भुगतान/बटुआ, खेल सामग्री/एकत्रीकरण, बोनस/मिशन, टूर्नामेंट, विपणन/सीआरएम, रिपोर्टिंग/बीआई।

बाध्य संदर्भ = डेटा मॉडल और भाषा अनुबंध।

प्रवाह बदलें ↔ कमांड: एक कमांड = एक लूप + इसका एसएलओ।

BFF (फ्रंटेंड के लिए बैकेंड): वेब/मोबाइल/पार्टनर के लिए अलग facades, ताकि ग्राहक पर "ऑर्केस्ट्रेशन" एकत्र न किया जा सके।

3) संचार: तुल्यकालिक बनाम अतुल्यकालिक

तुल्यकालिक (REST/gRPC): जब तत्काल प्रतिक्रिया की आवश्यकता होती है (जमा सीमा की जाँच)।

Asynchron (Kafka/NATS/SQS): घटनाओं और पृष्ठभूमि प्रक्रियाओं (कैशबैक एक्रिचुअल, मेलिंग, रेटिंग अपडेट)।

नियम:
  • महत्वपूर्ण पथ = न्यूनतम नेटवर्क हॉप्
  • क्रॉस-डोमेन एकीकरण - घटनाओं और संविदात्मक एपीआई के माध्यम से।
  • "5 + तुल्यकालिक कॉल की श्रृंखला" ऑनलाइन न बनाएं → EDA/sagas का उपयोग करें।

4) अनुबंध और संस्करण

अनुबंध एक: OpenAPI/AsyncAPI + स्कीमा रजिस्ट्री (एवरो/JSON स्कीमा)।

SemVer + संगतता: फ़ील्ड जोड़ ना ग्राहकों को नहीं तोड़ ता है.

उपभोक्ता-संचालित अनुबंध (सीडीसी): सीआई (बनाम प्रतिगमन) में ऑटो-चेक।

अस्वीकृति नीति: समर्थन विंडो (12-18 महीने), पुराने संस्करणों के लिए टेलीमेट्री।

5) घटनाएँ, साग और स्थिरता

आउटबॉक्स/ट्रांजेक्शन लॉग टेलिंग: परमाणु रिकॉर्ड "डेटा + इवेंट"।

सागा पैटर्न:
  • भुगतान/आउटपुट के लिए ऑर्केस्ट्रेशन (केंद्रीय समन्वयक)।
  • बोनस/मिशन के लिए कोरियोग्राफी (घटनाओं पर प्रतिक्रिया)।
  • Idempotence: 'EntyId + action + nonce', dedup रजिस्ट्री भंडारण पर कुंजी।
  • स्थिरता: "बाहरी" - घटनाओं के माध्यम से; "आंतरिक" - सेवा के भीतर लेनदेन।

6) डेटा और भंडारण

"अपना स्टोर" का सिद्धांत: प्रत्येक सेवा अपने स्वयं के डेटाबेस (योजनाओं का अलगाव) का मालिक है।

पहुँच पैटर्न द्वारा भंडारण चयन:
  • सख्त आक्रमणकारियों के साथ लेनदेन/शेष संबंधपरक (PostgreSQL) हैं।
  • घटनाएँ/लॉग - एपेंड-ओनली (काफ्का/रेडपांडा)।
  • कैश/सत्र - रेडिस/कीडीबी; लीडरबोर्ड - रेडिस सॉर्टेड सेट।
  • खोज - ओपनसर्च/इलास्टिक।
  • भौतिक पठन अनुमान (CQRS) - त्वरित सूची/रिपोर्ट।

7) विश्वसनीयता और स्थिरता

Timeouts/Retry jitter/Retry-बजट के साथ केवल idempotent संचालन के लिए।

सर्किट-ब्रेकर/सेवाओं के बीच आउटलियर-इजेक्शन।

बल्कहेड: "शोर" ऊपर की ओर के लिए अलग पूल।

दर प्रति-क्लाइंट/रूट, बैकप्रेशर (503 + रेट्री-आफ्टर) की सीमा।

डेड-लेटर + जहर-संदेश कतारों में हैंडलिंग।

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

ट्रेस: OpenTelemetry ('trace _ id' shlyuz→servisy→BD के माध्यम से)।

मेट्रिक्स: RPS, p50/p95/p99, त्रुटि दर 4xx/5xx, संतृप्ति (CPU/mem/कतार), व्यवसाय मेट्रिक्स (TTP, TtW)।

लॉग: संरचित JSON, PII/PAN/IBAN मास्किंग, 'ट्रेस _ id' द्वारा सहसंबंध।

SLO/अलर्ट: रूट/फंक्शन (उदाहरण के लिए, 'डिपॉजिट p95 ≤ 300 ms', 'सफलता ≥ 98। 5%`).

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

जीरो-ट्रस्ट: mTLS servis↔servis (SPIFFE/SPIRE), अल्पकालिक प्रमाणपत्र।

AuthN/Z: OAuth2/JWT (aud/scope/exp), भूमिकाओं के भेदभाव का गुण।

राज: केएमएस/सीक्रेट मैनेजर/सील किए गए रहस्य, कुंजी घुमाव।

जीडीपीआर/डेटा स्थानीयकरण: क्षेत्रीय समूह, एपीआई गेटवे पर भू-बाड़लगाना।

ऑडिट: अपरिवर्तनीय लॉग (WORM), व्यवस्थापक क्रियाओं का पता लगाना।

10) तैनाती और रिलीज

Containers/K8s: एक सेवा = एक तैनात; संसाधन/सीमा; PodDis बजट।

CI/CD: लिंटर्स, यूनिट/कॉन्ट्रैक्ट/इंटेग टेस्ट, सिक्योरिटी स्कैन, SBOM।

रिलीज: कैनरी/ब्लू-ग्रीन/छाया, विस्तार और अनुबंध के माध्यम से योजना पलायन।

ऑटोस्केल: सीपीयू + आरपीएस + p95 + कतार-गहराई द्वारा एचपीए; पतन पर नाली।

11) प्रदर्शन और लागत

प्रोफाइलिंग: p95/99 "सेवाओं और तरीकों से", लौ-रेखांकन।

कैचिंग: रीड-थ्रू/राइट-थ्रू; घटना द्वारा टीटीएल/विकलांगता।

डेटा स्थानीयता: गर्म डेटा को गणना के करीब रखें।

FinOps: लक्ष्य 60-70%, "गर्म पूल", निष्क्रिय श्रमिकों का ऑटो-ठहराव।

12) डोमेन टेम्पलेट (iGaming)

12. 1 भुगतान/बटुआ

सेवाएं: 'भुगतान-gw' (मुखौटा), 'बटुआ', 'psp-adperters-', 'धोखाधड़ी-जांच'।

स्ट्रीम: 'इनिट → रिजर्व → कैप्चर/रोलबैक' (गाथा)।

: 'इनिशिएटेड', ' आधिकारिक', ' Supted/असफल'।

Idempotency: 'Idempotency-Key', 'वॉलेट' में डेडअप।

12. 2 सीसीएम/अनुपालन

Сервисы: 'केसी-फ्लो', 'डॉक-स्टोरेज', 'प्रतिबंध-चेक', 'पेप-स्क्रीनिंग'।

События: 'Kyccसबमिट/स्वीकृत/अस्वीकृत', 'रिस्क अपडेटेड'।

ऑडिट और ईटीए: कार्य कतार, टाइम-लाइन मामला, पोस्ट-एक्शन।

12. 3 बोनस/मिशन

सेवाएं: 'बोनस-इंजन', 'वॉलेट-बोनस', 'पात्रता'।

कोरियोग्राफी: 'बेटप्लेस्ड → बोनसइंजन → BonusIfeed → WalletCredied'।

दुरुपयोग के खिलाफ सुरक्षा: पहचान अनुदान, सीमा, नियम सिम्युलेटर।

12. 4 टूर्नामेंट/लीडरबोर्ड

सेवाएं: 'टूर्नामेंट-एसवीसी', 'स्कोरिंग', 'लीडरबोर्ड'।

भंडारण: OLAP में Redis ZSET + आवधिक "फ्लश"।

События: 'अपडेटेड', 'टूरिज्म क्लोज्ड', 'रिवार्डस्टेड'।

13) अनुबंध + घटना उदाहरण (सरलीकृत)

OpenAPI (खंड) - बटुआ

yaml paths:
/v1/wallet/{userId}/credit:
post:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/CreditRequest'
responses:
'202': { description: 'Enqueued' }
components:
schemas:
CreditRequest:
type: object required: [amount, currency, reason, idempotencyKey]
properties:
amount: { type: number }
currency: { type: string, example: UAH }
reason: { type: string, enum: [Deposit, Bonus, Adjustment] }
idempotencyKey: { type: string }

AsyncAPI (खंड) - घटना

yaml channels:
wallet. credit. applied:
publish:
message:
name: WalletCreditApplied payload:
type: object required: [userId, amount, currency, sourceEventId]

14) परीक्षण

डोमेन नियमों के लिए इकाई/संपत्ति-आधारित।

सीडीसी (संधि/असेसबल) - प्रदाता/उपभोक्ता अनुबंध परीक्षण।

स्थानीय दलालों (Testconteners) के साथ एकीकरण।

महत्वपूर्ण प्रवाह E2E (registratsiya→depozit→start igry→vyvod)

अराजकता/विफल परीक्षण: पीएसपी शटडाउन/ब्रोकर ड्रॉप/ज़ोन लॉस।

15) मेट्रिक्स और एसएलओ (न्यूनतम)

सेवाओं की उपलब्धता: '≥99। 9% 'भुगतान/बटुआ के लिए।

विलंबता p95: महत्वपूर्ण पथ API ≤ 300-500 ms।

त्रुटि बजट: 0। 1–0. 5% प्रति तिमाही, बर्न-अलर्ट।

कतारें: लीड टाइम इवेंट्स (produce→consume), DLQ ≤ 0। 1%.

व्यवसाय: TTP, TtW, FTD-सफलता, KYC-TtV।

16) चेकलिस्ट

सेवा डिजाइन

  • स्पष्ट डोमेन सीमा और डेटा मालिक।
  • OpenAPI/AsyncAPI रजिस्ट्री में अनुबंध + स्कीमा।
  • एसएलओ/अलर्ट परिभाषित; मेट्रिक्स/ट्रेल्स/लॉग में बनाया गया है।
  • टाइमआउट/रिट्रे/आइडेम्पोटेंसी पॉलिसी।
  • स्कीमा पलायन: विस्तार और अनुबंध।

रिलीज से पहले

  • यूनिट/सीडीसी/एकीकरण परीक्षण हरा।
  • कैनरी मार्ग और रोलबैक योजना।
  • दर-सीमा/वजन मार्गों को कॉन्फ़िगर किया जाता है।
  • रहस्य/कुंजी/प्रमाणपत्र खोद रहे हैं।
  • फिचा झंडे और फॉलबैक तैयार किए जाते हैं।

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

डेटा बस के रूप में नेटवर्क: घटनाओं के बजाय गहरी तुल्यकालिक श्रृंखला।

सामान्य "भगवान" - सभी सेवाओं के लिए डीबी।

पहचान की कमी - डबल राइट-ऑफ/अर्क।

टेलीमेट्री और किल-स्विच के बिना डार्क रिलीज।

छिपा हुआ सत्र (बाहरी स्थिति के बजाय हर जगह चिपचिपाहट)।

संस्करण और सीडीसी के बिना "कोड में" अनुबंध।

सेवाओं के बजाय एपीआई गेटवे में तर्क (गेटवे = पतला)।

18) मोनोलिथ माइग्रेशन (स्ट्रैंगलर अंजीर)

1. मुखौटा गेटवे और प्राथमिक सर्किट चुनें (उदाहरण के लिए, भुगतान)।

2. बाइनरी लॉगिंग (आउटबॉक्स) को मोनोलिथ से घटनाओं में मिटाएँ.

3. धीरे-धीरे समापन बिंदुओं को एक नई सेवा (रूटिंग/कैनरी वेट) में स्थानांतरित करें।

4. मोनोलिथ को "कोर" पर संपीड़ित करें और इसे बंद करें।

19) स्टैक और इंफ्रास्ट्रक्चर (उदाह

संचार: REST/gRPC, काफ्का/NATS; स्कीमा रजिस्ट्री।

रिपॉजिटरी: PostgreSQL, Redis, OpenSearch, S3/MinIO; OLAP - क्लिकहाउस/BigQuery।

कंटेनर/ऑर्केस्ट्रेशन: यदि आवश्यक हो तो डॉकर, कुबर्नेट्स (इंग्रेस/गेटवे), सर्विस मेश (इस्तियो/लिंकर्ड)।

गेटवे: दूत/कोंग/ट्रेफिक/NGINX।

CI/CD: GitHub एक्शन/GitLab CI + ArgoCD/Flux; संधि/OWASP/ZAP।

अवलोकन: OpenTelemetry, Prometheus, Tempo/Jaeger, Loki।

20) अंतिम धोखा पत्र

डोमेन और डेटा जिम्मेदारी द्वारा डिजाइन सीमाएं।

सिंक्रोन - केवल जहां अब एक उत्तर की आवश्यकता है; बाकी घटनाएं हैं।

संविदा/योजनाएं/सीडीसी - प्रतिगमन बीमा।

सागास + आउटबॉक्स + पहचान - विश्वसनीयता की नींव।

अवलोकन और एसएलओ एक विकल्प नहीं है, लेकिन "तैयार" मानदंड है।

कैनरी/ब्लू-ग्रीन, माइग्रेशन के माध्यम से रिलीज़ - विस्तार और अनुबंध।

सुरक्षा/अनुपालन: mTLS, JWT, KMS, क्षेत्रीय डेटा।

सबसे पहले, एक मॉड्यूलर मोनोलिथ, फिर विकास - अगर पैमाने और टीम तैयार हैं।

Contact

हमसे संपर्क करें

किसी भी प्रश्न या सहायता के लिए हमसे संपर्क करें।हम हमेशा मदद के लिए तैयार हैं!

इंटीग्रेशन शुरू करें

Email — अनिवार्य है। Telegram या WhatsApp — वैकल्पिक हैं।

आपका नाम वैकल्पिक
Email वैकल्पिक
विषय वैकल्पिक
संदेश वैकल्पिक
Telegram वैकल्पिक
@
अगर आप Telegram डालते हैं — तो हम Email के साथ-साथ वहीं भी जवाब देंगे।
WhatsApp वैकल्पिक
फॉर्मैट: देश कोड और नंबर (उदा. +91XXXXXXXXXX)।

बटन दबाकर आप अपने डेटा की प्रोसेसिंग के लिए सहमति देते हैं।