संतुलन और पर्स: बहु-बटुआ वास्तुकला

1) बहु-बटुआ क्यों और क्या लक्ष्य

एक "बैलेंस = नंबर" प्रविष्टि iGaming की वास्तविकता को कवर नहीं करती है। अलग-अलग पर्स/सबकैश की आवश्यकता होती है: असली पैसा (नकद), बोनस फंड, दांव पूल, फ्रीस्पिन, कंप्यूटर पॉइंट, कभी-कभी मुद्रा पर्स (EUR/USD/BRL)।

वास्तुकला के उद्देश्य हैं:

धन सटीकता (दोहरी प्रविष्टि, श्रवण)।
राइट-ऑफ नीतियां (उदाहरण के लिए, पहले बोनस/वेगर, फिर नकदी)।
गति (p95 API ≤ 250-400 ms, वास्तविक समय में शर्त/निपटान)।
सुरक्षा और अनुपालन (केवाईसी/एएमएल, जिम्मेदार प्ले लिमिट, नियामक)।
स्केल: चोटियों - दसियों हज़ार ऑपरेशन/सेकंड, अरबों पोस्ट/महीने।

2) डेटा मॉडल: "लेजर + सबवॉलेट्स"

न्यूनतम संस्थाएँ

खाता: खिलाड़ी/ब्रांड/बाजार।

बटुआ: '{type: CASH	बोनस	दांव	एफएस	अंक, मुद्रा, स्थिति} '।
LedgerEntry (двойная запись): 'डेबिट _ अकाउंट', 'क्रेडिट _ अकाउंट', 'राशि', 'मुद्रा', 'ऑपरेशन _ id', 'श्रेणी', 'निर्मित _ at'।
पोस्टिंग: परमाणु व्यवसाय संचालन, 2 + LedgerEntry को जोड़ ती है।
पकड ़/आरक्षण: शर्त/निकासी के लिए धन का अस्थायी अवरोधन।
नीति: राइट-ऑफ/क्रेडिट प्राथमिकता नियम।
FXRate: कोर्स/सटीक/राउंडिंग नियम।
सीमा: दिन/माह/जिम्मेदार खेल।

तालिकाओं का उदाहरण (सरलीकृत)

sql
- डबल-एंट्री (व्यवसाय सहित) के लिए बैलेंस शीट खाते
खाते (आईडी, owner_user_id, प्रकार, मुद्रा, स्थिति,...)

- पोस्टिंग (दोहरी प्रविष्टि, व्यापार लेनदेन का संदर्भ)
ledger_entries (id, posting_id, debit_account_id, credit_account_id, amount_minor, मुद्रा, श्रेणी, operation_id, created_at)

- होल्ड्स (भंडार)
होल्ड्स (id, account_id, amount_minor, मुद्रा, कारण, expires_at, राज्य, operation_id, created_at)

- राइट-ऑफ नीतियां (प्राथमिकताएं)
spend_policies (आईडी, बाजार, wallet_priority jsonb, updated_at)

- क्रॉस विनिमय दरें fx_rates (ccy_from, ccy_to, दर, सटीकता, valid_from)

नियम: सत्य लेनदेन पत्रिका ('ledger _ entries') में रहता है। वर्तमान संतुलन या तो एक कुल (भौतिक स्नैपशॉट) है, या एक पत्रिका (महंगा, लेकिन केवल सच) से गणना की जाती है।

3) पर्स के प्रकार और उनका व्यवहार

पर्स	क्यूर	ऊपर कर सकते हैं	बंद लिखा जा सकता है	विशेष नियम
नकद	असली पैसा	PSP/मैनुअल एक्रिचुअल/रिटर्न	बोलियाँ, खरीद, निकासी	एएमएल/केवाईसी को प्रभावित करता है; लेनदेन रिकॉर्ड कि
बोनस	बोनस पैसा	प्रोमो/अभियान	दरें (नियमों के अनुसार)	जब वागर निष्पादित किया जाता है तो सीधे प्रदर्शित नहीं किया जाता है, नकद में परिवर्तित किया जाता है
दांव	"जमे हुए" बोनस के लिए लेखांकन	शर्त बोनस से ऑटो	खेल प्रदाता के पक्ष में लिखें	रिलीज नियम नियत करें/रद्द करें
FS (FreeSpins)	घूर्णन पैकेज	अभियान	स्लॉट में चुकौती	टी एंड सी में नकद समकक्ष तय किया गया है
अंक	लॉयल्टी/कॉम्प्स	गतिविधि	दुकान/स्टेटस	पैसा नहीं; एएमएल रिपोर्ट में शामिल नहीं

4) राइट-ऑफ नीतियां और प्राथमिकता क्रम

स्पष्ट रूप से धन के स्रोत के लिए एल्गोरिथ्म को औपचारिक रूप दें: उदाहरण (स्लॉट/कैसिनो):

1. सबसे पहले, WAGER से लिखें (यदि दांव सक्रिय है)।

2. फिर बोनस से समाप्त होने तक।

3. शेष CASH से है।

उदाहरण (खेल):

1. पहला CASH (नियामक/कर)।

2. फिर बोनस (फ्रीबेट), WAGER में अनुवाद।

पोस्टिंग में एक विशेषता के रूप में "नीति निर्णय" को सहेजें ताकि समर्थन और ऑडिट देखें "उन्होंने इसे क्यों लिखा।"

5) धन और संचालन का जीवन चक्र

जमा राशि

1. 'POST/वॉलेट/डिपॉजिट' - एक लंबित प्रविष्टि (PSP सॉसेज का इनबॉक्स) बनाएं।

2. वेबहुक PSP (HMAC हस्ताक्षर, 'ऑपरेशन _ id' द्वारा पहचान) क्रेडिट CASH, श्रेणी = 'DOPIT'।

3. हम 'बटुआ _ अद्यतन' घटना प्रकाशित करते हैं।

दर

1. 'POST/शर्त/स्थान' - स्रोत खाते (CASH/BONUS/WAGER) पर एक पकड़ (आरक्षित) बनाएं।

2. दर की पुष्टि करते समय, होल्ड डेबिट स्रोत का हस्तांतरण, प्रदाता के सेवा "निपटान" खाते का क्रेडिट है।

3. रद्द करने पर - रिलीज़ होल्ड।

निपटान (परिणाम)

लाभ: प्रदाता के "निपटान" खाते का डेबिट क्रेडिट CASH या पॉलिसी ।

नुकसान: खिलाड़ी को क्रेडिट के बिना लेनदेन के साथ प्रदाता के "खर्च" को बंद करें।

1. KYC/AML जांच, जिम्मेदार खेल सीमा।

2. निकासी राशि पर पकड़।

3. PSP की सफलता अंतिम डेबिट CASH क्रेडिट खाता "भुगतान" है।

4. PSP → रिलीज़ होल्ड विफल रहा।

6) आइडेम्पोटेंस और एक बार "अर्थ के भीतर"

हर जगह एक अद्वितीय सूचकांक के साथ 'operation _ id' (UUID/बढ़ाया ULID)। पुनः अनुरोध - पिछले लेनदेन की स्थिति।

PSP/गेम प्रदाता वेबहूक: 'इवेंट _ id + सिग्नेचर' द्वारा dedupe के साथ इनबॉक्स तालिका। प्रक्रमण - पहचान कार्यकर्ता (आउटबॉक्स पैटर्न)।

क्लाइंट के लिए HTTP पर पहचान-कुंजी; TTL ≥ 24-72 घंटे स्टोर करें।

7) आरक्षित और धारित

होल्ड एक राइट-ऑफ नहीं है, लेकिन उपलब्ध संतुलन का "फ्रीज" है।

नियम:

जीवन धारण करें: seconds→minutes (दर) या घंटे (आउटपुट)।
पकड़ आंशिक रूप से या पूरी तरह से बुझ सकती है (आंशिक समझौता)।
जब एक्सपायर - स्वचालित रिलीज और घटना।
'होल्ड _ id' ↔ 'शर्त _ id/निकासी _ id' संबंध रखें.

8) मुद्राएं, एफएक्स और राउंडिंग

मौद्रिक मात्रा - लघु इकाइयों (सेंट), प्रकार - पूर्णांक में।

बैंक राउंडिंग (राउंड हाफ टू ईवन) या टी एंड सी द्वारा

FX: 'CASH (EUR)' ↔ 'CASH (USD)' पर्स को विभाजित करना बेहतर है। एक अलग ऑपरेशन के रूप में परिवर्तित करें:

'डेबिट ईयूआर, क्रेडिट FX_EURUSD' और' डेबिट FX_EURUSD, क्रेडिट यूएसडी '- ऑडिट के लिए पारदर्शी।
विवाद में पाठ्यक्रम को स्वचालित रूप से "पहुंचना" निषिद्ध है; सभी नियम एफएक्स नीति में हैं।

9) जिम्मेदार खेल और सीमा

जमा/शर्त/हानि/सत्र सीमा (दिन/सप्ताह/महीना), शीतलन-बंद, स्व-बहिष्करण।

होल्ड/डेबिट से पहले प्री-चेक के रूप में लागू किया गया।

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

10) बटुए के चारों ओर धोखाधड़ी रोधी संकेत

डिवाइस क्लस्टर/एएसएन, लगातार छोटी जमा - बड़ी निकासी, वाशिंग पैटर्न।

बिन/देश/उपकरण द्वारा 'जमा/भीतर' पर वेग सीमा।

प्राप्तकर्ताओं के लिए ब्लॉक सूची (पर्स/IBAN), "खच्चरों" की सूची।
वॉलेट इवेंट्स - स्कोरिंग फीचर स्टोर (लॉगिन/डिपॉजिट/रेट) में।

11) स्थिरता और प्रदर्शन

सच बनाम कैश

सत्य खाते में है। "बैलेंस प्राप्त करें" एपीआई के लिए, भौतिक स्नैपशॉट ('उपयोगकर्ता _ id + वॉलेट _ type, संस्करण') रखें।

लिखें: डेटाबेस में एक लेनदेन → कैश को अमान्य करें।

"भारी" प्रवाह (लाइव) में, निकासी/बड़ेदांव से पहले शॉर्ट-टीटीएल 1-5 एस + अनिवार्य सत्य जांच उपयुक्त है।

स्केलिंग

'user _ id' (मॉड्यूल/रैंकिंग) द्वारा शार्टिंग, CASH बनाम BONUS के लिए अलग शार्ड पूल।

हॉट कुंजी (VIP/bots) - 'user _ id' द्वारा coalessing का अनुरोध करें।

अतुल्यकालिक एकत्रीकरण (पृष्ठभूमि में 'पोस्टिंग' → "स्नैपशॉट-अपडेट" की रचना करें)।

12) एपीआई अनुबंध (छद्म)

संतुलन

http
GET/v1/वॉलेट? प्रकार = CASH, BONUS
→ 200 {"पर्स": [
{"प्रकार ": "CASH ", "मुद्रा ": "EUR ": "उपलब्ध": 12050," होल्ड": 500," संस्करण": 1942}, {"प्रकार ": "बोनस ", "मुद्रा ": "EUR ", "उपलब्ध": 3000," weger _ req": 15000}
]}

शर्त (पकड़के साथ)

http
POST/v1/दांव/स्थान
{"बेट _ आईडी ": "बी _ 123 ", "राशि ": 500, "मुद्रा ":" ईयूआर"," स्रोत _ नीति":" कैसीनो _ डिफ़ॉल्ट", "idempotency_key":"ik_abc"}}
→ 201 {"स्थिति ": "HELD ", "hold _ id ":" h _ 789"," expires _ in": 30}

बस्ती

http
POST/v1/दांव/समझौता
{"बेट _ आईडी ": "बी _ 123 ", "परिणाम":" विन"," पेआउट": 1250}
→ 200 {"स्थिति ": "SUTED "," cash _ delta": + 1250}

http
POST/v1/निकासी
{"निकालें _ id ": "w _ 456 ", "राशि ": 10000," मुद्रा":" EUR"," विधि":" सेपा", "idempotency_key":"ik_def"}
→ 202 {"राज्य ": "पेंडिंग ", "नेक्स्ट _ चेक _ सेकंड ": 2, "स्टेटस _ url": "/v1/निकासी/w _ 456"}

13) पोस्टिंग के उदाहरण (डबल-एंट्री)

जमा €100 (PSP शुल्क €1, commis। खाता - अलग)


डेबिट: PSP_Settlements (EUR) 10000
साभार: उपयोगकर्ता। CASH (EUR) 10000

डेबिट: उपयोगकर्ता। CASH (EUR) 100 (शुल्क बदलाव)
साभार: PSP_Fees (EUR) 100

BONUS से शर्त (WAGER में स्थानांतरण)


डेबिट: उपयोगकर्ता। बोनस (EUR) 500
साभार: उपयोगकर्ता। WAGER (EUR) 500 (दांव पर ले जाएं)
डेबिट: उपयोगकर्ता। WAGER (EUR) 500
साभार: प्रदाता। सेटलमेंट (EUR) 500 (लिखित दर)

जीतें €12। 5 → CASH में


डेबिट: प्रदाता। सेटलमेंट (EUR) 1250
साभार: उपयोगकर्ता। CASH (EUR) 1250

होल्ड राइट-ऑफ (HOLD सेवा खाते के माध्यम से अहसास)


डेबिट: उपयोगकर्ता। CASH (EUR) 500
साभार: उपयोगकर्ता। HOLD (EUR) 500 (पकड़द्वारा बनाया गया)
- बसने पर
डेबिट: उपयोगकर्ता। HOLD (EUR) 500
साभार: प्रदाता। सेटलमेंट (EUR) 500
- रद्द करने पर
डेबिट: उपयोगकर्ता। HOLD (EUR) 500
साभार: उपयोगकर्ता। CASH (EUR) 500

14) लेखा परीक्षा, अपरिवर्तनीयता और अनुपालन

लॉग के लिए WORM/प्रतिरक्षा (ऑब्जेक्ट स्टोरेज/WAL आर्काइव)।

एक्सेस मेटा-लॉग: जिन्होंने सीमाओं को पढ़ा/बदल दिया, जिन्होंने मैनुअल समायोजन किया (केवल औचित्य के साथ "समायोजन-पोस्टिंग" के माध्यम से)।
जीडीपीआर/नियामक: 5-10 वर्षों के लिए लेनदेन का भंडारण (अधिकार क्षेत्र द्वारा), खिलाड़ी के लिए बस्तियों की पारदर्शिता (राइट-ऑफ/दांव का इतिहास)।

15) दोष सहिष्णुता और डीआर

मल्टी-एज़अनिवार्य; बटुए के लिए डीआर-क्षेत्र: क्षेत्र में सिंक प्रतिकृति, एसिंक - क्षेत्र में; PITR सक्षम है।

स्टैंडबाय को बढ़ावा दें - केवल मैन्युअल रूप से चेकलिस्ट (विभाजन-मस्तिष्क को बाहर करना)।

जांच साप्ताहिक (परीक्षण-पुनर्स्थापन), नियंत्रण रिपोर्ट की मात्रा का सामंजस्य बहाल करें।

16) बटुआ अवलोकन

SLI: 'डिपॉजिट _ सक्सेस _ रेशियो', 'रिक्वाइट _ सक्सेस _ रेशियो', 'बेट _ होल्ड _ लेटेंसी _ p95', 'सेटलमेंट _ लेटेंसी _ p95'।

Тех: 'ledger _ postings _ rate', 'db _ connections _ saturation', 'कतार _ lag _ seconds', 'hold _ expired _ reate'।

अलर्ट: पीएसपी सफलता बाजार में गिरावट, 'होल्ड _ एक्सपायर्ड _ रेट' ग्रोथ, गेम प्रदाता सिंक से बाहर (कोई पुष्टि नहीं> एन मिनट)।

17) परीक्षण और गुणवत्ता नियंत्

PSP/गेम प्रदाताओं (वेबहूक/हस्ताक्षर) के साथ अनुबंध परीक्षण।

पैसे की संपत्ति-आधारित परीक्षण: प्रत्येक पोस्टिंग में डेबिट = = क्रेडिट का योग।
फ़ज ़/अराजकता: PSP/प्रदाता देरी, वेबहुक दोहराता है, नेटवर्क फ्लैपी।
लोड: फट दांव (60-120 एस), भिगोना (4-8 एच), नियंत्रण 'कतार _ लाग' और p99।

18) उत्पादन तत्परता चेकलिस्ट

डबल लेजर एंट्री, 'ऑपरेशन _ आईडी' के साथ पोस्टिंग के माध्यम से सभी ऑपरेशन।
स्पष्ट खर्च-नीतियां और प्राथमिकता क्रम (पोस्टिंग के साथ बनी रहती
टीटीएल/आंशिक निपटान/समाप्ति, शर्त/वापसी के साथ संचार के साथ रखता है।
इनबॉक्स/आउटबॉक्स, एचएमएसी वेबहूक, सभी सीमाओं पर पहचान।
व्यक्तिगत CASH/BONUS/WAGER/FS/POINTS पर्स; मुद्राओं से विभाजित।
एफएक्स और मामूली राउंडिंग; रूपांतरण - एक अलग ऑपरेशन।
जिम्मेदार खेल को पकड़ ने/डेबिट करने की सीमा; असफलता लेखा परीक्षा।
महत्वपूर्ण कार्यों से पहले कैश (लघु TTL) + आवश्यक सत्य जांच पढ़ें।
PITR/बैकअप/DR स्क्रिप्ट; मैनुअल प्रोत्साहन, नियमित डीआर अभ्यास।
डैशबोर्ड/अलर्ट SLI + तकनीकी; WORM लॉग और एक्सेस लॉग।
लोड/अराजकता परीक्षण; पीएसपी/प्रदाताओं के साथ सुलह रिपोर्ट।

सारांश फिर से शुरू करें

मल्टी-वॉलेट आर्किटेक्चर "कई बैलेंस नंबर" नहीं है, लेकिन एक दोहरी प्रविष्टि, खर्च करने वाली नीतियों, आरक्षण और ऑडिटिंग और खिलाड़ियों के लिए एक पारदर्शी निशान के साथ एक वित्तीय प्रणाली है। लॉग में सच्चाई रखें, होल्ड और आइडेम्पोटेंस, अलग पर्स और मुद्राएं, स्वचालित सुलह और डीआर। इस तरह बटुआ यूएक्स के लिए तेज होगा, पैसे के लिए सटीक और पीक लोड और नियामक जांच के लिए प्रतिरोधी।