التوازن والمحافظ: هندسة معمارية متعددة المحافظ
1) لماذا المحفظة المتعددة وما هي الأهداف
لا يغطي إدخال «الرصيد = الرقم» حقيقة iGaming. هناك حاجة إلى محافظ/حسابات فرعية منفصلة: أموال حقيقية (نقدية)، أموال إضافية، تجمع رهانات، مسامير مجانية، نقاط كمبيوتر، أحيانًا محافظ عملات (يورو/دولار أمريكي/BRL).
وتتمثل أهداف الهندسة المعمارية فيما يلي:- دقة النقود (القيد المزدوج، القابلية للمراجعة).
- سياسات الشطب (على سبيل المثال، المكافأة/الفجر أولاً، ثم النقد).
- السرعة (p95 API ≤ 250-400 mm، الرهان/التسوية في الوقت الفعلي).
- السلامة والامتثال (KYC/AML، حدود اللعب المسؤولة، المنظمون).
- المقياس: الذروة → عشرات الآلاف من العمليات/ثانية، مليارات الوظائف/الشهر.
2) نموذج البيانات: "Ledger + Subwallets'
الحد الأدنى من الكيانات
الحساب: لاعب/علامة تجارية/سوق.
مثال على الجداول (مبسطة)
sql
- حسابات الميزانية العمومية للقيد المزدوج (بما في ذلك الأعمال التجارية)
(هوية، owner_user_id، نوع، عملة، حالة،...)
- النشر (القيد المزدوج، الإشارة إلى المعاملات التجارية)
ledger_entries (الهوية، posting_id، debit_account_id، credit_account_id، amount_minor، العملة، الفئة، operation_id، created_at)
- عقد (احتياطيات)
(الهوية، 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)القاعدة: الحقيقة موجودة في مجلة المعاملات («دفتر الأستاذ _ إدخالات»). الرصيد الحالي هو إما مجمع (لقطة ملموسة)، أو يتم حسابه من مجلة (باهظة الثمن، ولكن صحيح فقط).
3) أنواع المحافظ وسلوكها
4) سياسات الشطب ونظام الأولوية
إضفاء الطابع الرسمي الواضح على خوارزمية مصدر الأموال: مثال (فتحات/كازينوهات):1. أولاً، شطب من WAGER (إذا كان الرهان نشطًا).
2. ثم من BONUS حتى استنفد.
3. الباقي من CASH.
مثال (الرياضة):1. أول نقدي (منظم/ضريبة).
2. ثم BONUS (freebet)، مترجمًا إلى WAGER.
احفظ «قرار السياسة» كميزة في المنشورات حتى يرى الدعم والتدقيق «سبب شطبها».
5) دورة حياة الأموال والعمليات
إيداع
1. "POST/wallet/deposit' → إنشاء إدخال معلق (صندوق الوارد لنقانق PSP).
2. Webhook PSP (توقيع HMAC, idempotency by 'operation _ id') → credit CASH, category = 'DEPOSIT'.
3. ننشر حدث «المحفظة _ المحدث».
معدل
1. «POST/bet/place» → إنشاء حجز (احتياطي) على حساب المصدر (CASH/BONUS/WAGER).
2. وعند تأكيد السعر، يكون نقل الحيازة → مصدر الخصم، وائتمان حساب «تسوية» الخدمة لمقدم الخدمة →.
3. عند الإلغاء - تعليق الإصدار.
تسوية (نتيجة)
الربح: خصم حساب «التسوية» لمقدم الائتمان → CASH أو WAGER→BONUS→CASH السياسة.
الخسارة: إغلاق «نفقة» المزود بمعاملة → دون اعتمادات للاعب.
1. فحص KYC/AML، حدود اللعب المسؤولة.
2. انتظر مبلغ السحب
3. نجاح PSP → الخصم النهائي CASH → حساب الائتمان «الدفع».
4. فشل تعليق إطلاق سراح → PSP.
6) الفراغ ومرة واحدة بالضبط «بالمعنى»
في كل مكان «operation _ id» (UUID/ULID المحسن) مع مؤشر فريد. إعادة الطلب → حالة المعاملة السابقة.
خطوط الويب PSP/مزود اللعبة: جدول Inbox مع dedupe بواسطة «event _ id + signature». المعالجة - العامل الخفي (نمط Outbox).
Edempotency-Key on HTTP for the client; متجر TTL ≥ 24-72 ساعة.
7) الاحتياطيات والعقود
التمسك ليس شطبًا، ولكنه «تجميد» للرصيد المتاح.
القواعد:- عقد الحياة: seconds→minutes (معدل) أو ساعات (إخراج).
- يمكن إخماد الحجز جزئيًا أو كليًا (تسوية جزئية).
- عند انتهاء الصلاحية - الإصدار التلقائي والحدث.
- احتفظ بعلاقة 'hold _ id' ↔ 'bet _ id/سحب _ id'.
8) العملات والعملات الأجنبية والتقريب
المبالغ النقدية - بالوحدات الثانوية (سنت)، النوع - عدد صحيح.
تقريب البنك (النصف إلى الزوجي) أو T & C.
FX: «CASH (EUR)» ↔ «CASH (USD)» من الأفضل تقسيم المحافظ. تحويل كعملية منفصلة:- "debit EUR، credit FX_EURUSD' و" debit FX_EURUSD، credit USD "- شفاف للتدقيق.
- يحظر «الوصول» تلقائيا إلى مسار النزاع ؛ جميع القواعد في سياسة العملات الأجنبية.
9) اللعب المسؤول والحدود
حدود الإيداع/الرهان/الخسارة/الجلسة (يوم/أسبوع/شهر)، التهدئة، الاستبعاد الذاتي.
نفذ كفحص مسبق قبل الاحتجاز/الخصم.
سجلات الفشل - في سجل تدقيق منفصل، متاح للدعم والمنظم.
10) إشارات مكافحة الاحتيال حول المحفظة
مجموعات الأجهزة/ASNs، الرواسب الصغيرة المتكررة → عمليات السحب الكبيرة، أنماط الغسيل.
حدود السرعة على 'الإيداع/داخل' بواسطة BIN/country/device.
قوائم المجموعات للمستلمين (المحافظ/IBAN)، قائمة «البغال».
أحداث المحفظة → في متجر ميزات التسجيل (تسجيل الدخول/الإيداع/السعر).
11) الاتساق والأداء
صحيح مقابل ذاكرة التخزين المؤقت
الحقيقة في دفتر الأستاذ. للحصول على واجهة برمجة التطبيقات «احصل على التوازن»، احتفظ باللقطة المجسدة («المستخدم _ المعرف + المحفظة _ النوع → balance_minor، الإصدار»).
اكتب: معاملة في قاعدة البيانات → تبطل المخبأ.
في التدفق «الثقيل» (مباشر)، يتم التحقق من الحقيقة الإلزامية لـ TTL 1-5 + قبل الانسحاب/الرهان الكبير المناسب.
حرق
الشحن بواسطة 'user _ id' (وحدة/ترتيب)، مجمعات شظايا منفصلة لـ CASH مقابل BONUS.
مفاتيح ساخنة (VIP/bots) - طلب دمج بواسطة 'user _ id'.
التجميعات غير المتزامنة (تكوين 'النشر' → 'Snapshot-update' في الخلفية).
12) عقود API (زائفة)
التوازن
http
احصل على/v1/محافظ ؟ الأنواع = النقد، المكافأة
→ 200 {«محافظ»: [
{«نوع «: «نقد «، «عملة «: «يورو «، «متاح»: 12050،» عقد»: 500،» إصدار»: 1942}، {«نوع «: «مكافأة «، «عملة «: «يورو «، «متاح»: 3000،» رهان _ req»: 15000}
]}الرهان (مع الانتظار)
http
POST/v1/الرهانات/المكان
{«bet _ id»: «b _ 123»، «المبلغ»: 500، «العملة»: «EUR»، «source _ policy»: «casino _ default'،» idempotency_key":"ik_abc"}
→ 201 {"الحالة": "HOLD"، "hold _ id": "h _ 789"، "تنتهي صلاحيتها _ in': 30}تسوية
http
POST/v1/bets/settle
{"bet _ id": "b _ 123"، "النتيجة": "WIN"، "payout': 1250}
→ 200 {«الحالة «: «SETLED «،» cash _ delta»: + 1250}http
POST/v1/supplications
{"سحب _ id ": "w _ 456 "، "المبلغ ": 10000،" العملة":" EUR"،" الطريقة":" sepa"، "idempotency_key":"ik_def"}
→ 202 {«دولة»: «معلقة»، «next _ check _ sec': 2،» status _ url': «/v1/submals/w _ 456 »}13) أمثلة على الوظائف (مدخل مزدوج)
€100 الإيداع (رسوم PSP €1، commis. حساب - منفصل)
الخصم: PSP_Settlements (يورو) 10000
الائتمان: المستخدم. النقدية (اليورو) 10000
الخصم: المستخدم. النقد (اليورو) 100 (نوبة رسوم)
الائتمان: PSP_Fees (يورو) 100الرهان €5 من BONUS (التحويل إلى WAGER)
الخصم: المستخدم. مكافأة (500 يورو)
الائتمان: المستخدم. الرهان (يورو) 500 (انتقل إلى الرهان)
الخصم: المستخدم. الرهان (باليورو) 500
الائتمان: المزود. التسوية (500 يورو) (السعر المشطوب)اربح €12. 5 → نقدا
الخصم: المزود. التسوية (اليورو) 1250
الائتمان: المستخدم. النقد (اليورو) 1250تعليق الشطب (التحقق من خلال حساب خدمة HOLD)
الخصم: المستخدم. النقدية (500 يورو)
الائتمان: المستخدم. HOLD (EUR) 500 (تم إنشاؤه بواسطة عقد)
-- في تسوية
الخصم: المستخدم. HOLD (يورو) 500
الائتمان: المزود. التسوية (500 يورو)
- عند الإلغاء
الخصم: المستخدم. HOLD (يورو) 500
الائتمان: المستخدم. النقدية (500 يورو)14) مراجعة الحسابات والثبات والامتثال
WORM/immunity for log (object storage/WAL archive).
الوصول إلى السجلات الوصفية: من قرأ/غير الحدود، ومن أجرى تعديلات يدوية (فقط من خلال «نشر التعديل» مع التبرير).
اللائحة العامة لحماية البيانات/الجهات التنظيمية: تخزين المعاملات لمدة 5-10 سنوات (حسب الولاية القضائية)، شفافية التسويات بالنسبة للاعب (تاريخ الشطب/الرهان).
15) تحمل الأخطاء و DR
إلزامية تعدد المناطق الحائزة للأسلحة ؛ منطقة DR للمحفظة: النسخ المتزامن في المنطقة، async - إلى المنطقة ؛ تم تمكين PITR.
تعزيز الاستعداد - فقط يدويًا عن طريق قائمة المراجعة (باستثناء تقسيم الدماغ).
استعادة الفحص الأسبوعي (استعادة الاختبار)، ومطابقة كمية تقارير المراقبة.
16) إمكانية مراقبة المحفظة
SLI: «الإيداع _ النجاح _ النسبة»، «سحب _ النجاح _ النسبة»، «الرهان _ hold _ latency _ p95»، «التسوية _ الكمون _ p95».
Тех: "دفتر الأستاذ _ المنشورات _ المعدل"، "db _ connections _ sitation"، "قائمة الانتظار _ lag _ seconds'،" عقد _ منتهي الصلاحية _ معدل ".
التنبيهات: انخفاض نجاح PSP في السوق، نمو «عقد _ منتهي الصلاحية _ السعر»، مزود اللعبة خارج المزامنة (لا توجد تأكيدات> N min).
17) الاختبار ومراقبة الجودة
اختبارات العقد مع PSP/مزودي الألعاب (خطوط الويب/التوقيعات).
اختبارات المال على أساس الملكية: مجموع الديون = = مجموع الاعتمادات في كل منشور.
Fuzz/الفوضى: تأخيرات PSP/المزود، تكرار خطاف الويب، flappies الشبكة.
الحمل: رهانات انفجار (60-120 ثانية)، نقع (4-8 ساعة)، تحكم في «قائمة الانتظار _ lag» و p99.
18) قائمة مرجعية لاستعداد الإنتاج
- إدخال دفتر الأستاذ المزدوج، وجميع العمليات عبر Posting مع 'operation _ id'.
- سياسات الإنفاق الواضحة وترتيب الأولويات (يستمر في النشر).
- عقد مع TTL/تسوية/انتهاء صلاحية جزئية، الاتصال مع الرهان/السحب.
- صندوق الوارد/Outbox، خطافات الويب HMAC، الخصوصية على جميع الحدود.
- محافظ النقد الفردية/المكافأة/الرهان/الخدمة المالية/النقاط ؛ مقسمة حسب العملات.
- FX والتقريب الطفيف ؛ التحويل - عملية منفصلة.
- حدود اللعب المسؤولة للحجز/الخصم ؛ مراجعة حسابات الفشل.
- قراءة ذاكرة التخزين المؤقت (TTL القصيرة) + يتطلب فحص الحقيقة قبل الإجراءات الحرجة.
- PITR/النسخ الاحتياطية/نصوص DR ؛ الترويج اليدوي، تمارين DR منتظمة.
- لوحات المعلومات/التنبيهات التقنية SLI + ؛ سجلات WORM وسجلات الوصول.
- اختبارات التحميل/الفوضى ؛ تقارير التسوية مع PSP/مقدمي الخدمات.
ملخص السيرة الذاتية
بنية المحافظ المتعددة ليست «أرقام توازن كثيرة»، ولكنها نظام مالي ذو دخول مزدوج وسياسات إنفاق وحجز ومسار شفاف للتدقيق واللاعبين. احتفظ بالحقيقة في السجل، واستخدم الثباتات والغباء، وفصل المحافظ والعملات، وأتمتة التسوية و DR. بهذه الطريقة ستكون المحفظة سريعة بالنسبة لـ UX، ودقيقة بالنسبة للمال ومقاومة لأحمال الذروة والفحوصات التنظيمية.
