Crypto Casino
Torrent Dişli
Denge ve cüzdanlar: çoklu cüzdan mimarisi
1) Neden çoklu cüzdan ve hangi hedefler
Bir "denge = sayı" girişi iGaming'in gerçekliğini kapsamaz. Ayrı cüzdanlara/alt hesaplara ihtiyaç vardır: gerçek para (nakit), bonus fonları, bahis havuzu, freespins, bilgisayar puanları, bazen para cüzdanları (EUR/USD/BRL).
Mimarinin hedefleri şunlardır:- Para doğruluğu (çift giriş, denetlenebilirlik).
- Silme politikaları (örneğin, önce bonus/vager, sonra nakit).
- Hız (p95 API ≤ 250-400 ms, gerçek zamanlı bahis/yerleşim).
- Güvenlik ve uyumluluk (KYC/AML, sorumlu oyun limitleri, düzenleyiciler).
- Ölçek: Zirveler - on binlerce işlem/saniye, milyarlarca gönderi/ay.
2) Veri modeli: "Ledger + Subwallets"
Minimal varlıklar
Hesap: oyuncu/marka/pazar.
Tablo örneği (basitleştirilmiş)
sql
- Çift giriş için bilanço hesapları (işletme dahil)
Hesaplar (id, owner_user_id, tür, para birimi, durum,...)
- Gönderme (çift giriş, ticari işleme referans)
ledger_entries (id, posting_id, debit_account_id, credit_account_id, amount_minor, para birimi, kategori, operation_id, created_at)
- Tutar (rezervler)
(id, account_id, amount_minor, para birimi, sebep, expires_at, devlet, operation_id, created_at)
- Silme politikaları (öncelikler)
spend_policies (id, market, wallet_priority jsonb, updated_at)
- Çapraz döviz kurları fx_rates (ccy_from, ccy_to, oran, hassasiyet, valid_from)Kural: Gerçek, işlem günlüğünde ('ledger _ entries') yaşar. Mevcut denge ya bir agregadır (materyalize anlık görüntü) ya da bir dergiden hesaplanır (pahalı, ancak yalnızca doğru).
3) Cüzdan türleri ve davranışları
4) Silme politikaları ve öncelik sırası
Fonların kaynağı için algoritmayı açıkça resmileştirin: Örnek (slotlar/casinolar):1. İlk olarak, WAGER'dan yazın (eğer bahis aktifse).
2. Sonra BONUS'tan tükenene kadar.
3. Geri kalanı ise nakittir.
Örnek (spor):1. İlk CASH (regülatör/vergi).
2. Sonra BONUS (freebet), WAGER'a çevirerek.
"Politika kararını" Gönderilerde bir özellik olarak kaydedin, böylece destek ve denetim "neden yazdıklarını" görür.
5) Para ve işlemlerin yaşam döngüsü
Depozito
1. 'POST/cüzdan/depozito' - bekleyen bir giriş oluşturun (PSP sosisinin gelen kutusu).
2. Webhook PSP (HMAC imzası, 'operation _ id'ile idempotency) - kredi NAKIT, kategori =' MEVDUAT '.
3. 'wallet _ updated' olayını yayınlıyoruz.
Oranı
1. 'POST/bet/place' - kaynak hesapta bir bekletme (rezerv) oluşturun (CASH/BONUS/WAGER).
2. Oranı onaylarken, bekletmenin transferi - borç kaynağı, sağlayıcının hizmet "yerleşim" hesabının kredisi -.
3. İptal üzerine - serbest bırakma bekletme.
Yerleşim (sonuç)
Kazanç: Sağlayıcının "uzlaştırma" hesabının borçlandırılması - kredi CASH veya poliçe WAGER - BONUS - CASH.
Kayıp: Sağlayıcının "masrafını" oyuncuya kredi vermeden bir işlemle kapatın.
1. KYC/AML kontrolü, sorumlu oyun limitleri.
2. Para çekme miktarını tutun.
3. PSP'nin başarısı - son borç CASH - kredi hesabı "ödeme".
4. PSP - serbest bırakma bekletmesi başarısız oldu.
6) Idempotence ve tam olarak bir kez "anlam içinde"
Her yerde 'operation _ id' (UUID/geliştirilmiş ULID) benzersiz bir dizin ile. Yeniden talep - geçmiş işlemin durumu.
PSP/oyun sağlayıcısı webhooks: 'Event _ id + signature'ile tekilleştirilmiş gelen kutusu tablosu. İşleme - idempotent işçi (Outbox desen).
İstemci için HTTP üzerinde Idempotency-Key; 24-72 saat ≥ TTL'yi saklayın.
7) Rezervler ve tutarlar
Hold bir silme işlemi değil, mevcut bakiyenin "dondurulması'dır.
Kurallar:- Tutma ömrü: saniyeler - dakikalar (oran) veya saatler (çıkış).
- Tutma kısmen veya tamamen söndürülebilir (kısmi yerleşme).
- Süresi dolduğunda - otomatik sürüm ve olay.
- 'Hold _ id' ↔ 'bet _ id/withdraw _ id' ilişkisini koruyun.
8) Para birimleri, FX ve yuvarlama
Parasal miktarlar - küçük birimler (sent), tip - tam sayı.
Banka yuvarlama (yarım ila çift yuvarlak) veya T&C tarafından
FX: 'CASH (EUR)' ↔ 'CASH (USD)' cüzdanları bölmek daha iyidir. Ayrı bir işlem olarak dönüştürme:- 'Borç EUR, kredi FX_EURUSD' ve' borç FX_EURUSD, kredi USD '- denetim için şeffaf.
- Bir anlaşmazlıkta kursa otomatik olarak "ulaşmak" yasaktır; Tüm kurallar FX politikasındadır.
9) Sorumlu oyun ve limitler
Depozito/Bahis/Kayıp/Oturum limitleri (gün/hafta/ay), soğuma, kendini dışlama.
Bekletme/borçlandırmadan önce ön kontrol olarak uygulanır.
Arıza günlükleri - ayrı bir denetim günlüğünde, destek ve düzenleyici tarafından kullanılabilir.
10) Cüzdan etrafında dolandırıcılık karşıtı sinyaller
Cihaz kümeleri/ASN'ler, sık sık küçük para yatırma - büyük para çekme, yıkama modelleri.
BIN/ülke/cihaz tarafından 'depozito/içinde' hız sınırları.
Alıcılar için blok listeleri (cüzdanlar/IBAN), "katırlar" listesi.
Cüzdan olayları - puanlama özelliği mağazasında (giriş/para yatırma/oran).
11) Tutarlılık ve performans
True vs önbellek
Gerçek defterde yazılı. "Get balance" API'si için, gerçekleştirilmiş anlık görüntüyü saklayın ('user _ id + wallet _ type _ balance_minor, version').
Yazma: veritabanındaki bir işlem önbelleği geçersiz kılar.
"Ağır" akışta (canlı), para çekme/büyük bahis uygun olmadan önce kısa-TTL 1-5 s + zorunlu doğruluk kontrolü.
Haşlama
'User _ id' (modül/sıralama) ile sharding, CASH vs BONUS için ayrı shard havuzları.
Kısayol tuşları (VIP/botlar) - 'user _ id'tarafından birleştirme isteğinde bulunun.
Eşzamansız toplamalar (arka planda 'gönderme' - "anlık görüntü güncellemesi" oluşturun).
12) API sözleşmeleri (pseudo)
Denge
http
GET/v1/cüzdanlar? Türleri = NAKIT, BONUS
200 {"cüzdan": [
{"type ": "CASH ", "currency ": "EUR ", "available": 12050," hold": 500," version": 1942}, {"type ": "BONUS ", "currency ": "EUR ", "available": 3000," wager _ req": 15000}
]}Bahis (bekletme ile)
http
POST/v1/bahisler/yer
{"bet _ id":'b _ 123 "," amount ": 500," currency ":" EUR "," source _ policy ":" casino _ default "," idempotency_key":"ik_abc"}
^ 201 {"status": "HELD", "hold _ id":'h _ 789 "," expires _ in ": 30}Yerleşim
http
POST/v1/bets/settle
{"bet _ id":'b _ 123 "," result ":" WIN "," payout ": 1250}
^ 200 {"status ": "SETTLED "," cash _ delta": + 1250}http
POST/v1/para çekme
{"puld _ id":'w _ 456 "," amount ": 10000," currency ":" EUR "," method ":" sepa "," idempotency_key":"ik_def"}
^ 202 {"durum ": "BEKLEMEDE ", "next _ check _ sec ": 2, "durum _ url": "/v1/para çekme/w _ 456"}13) İlanların örnekleri (çift giriş)
Depozito €100 (PSP ücreti €1, commis. hesap - ayrı)
Borç: PSP_Settlements (EUR) 10000
Kredi: Kullanıcı. NAKIT (EUR) 10000
Debit: Kullanıcı. NAKIT (EUR) 100 (ücret değişimi)
Kredi: PSP_Fees (EUR) 100BONUS'tan 5 € bahis yapın (WAGER'a transfer)
Debit: Kullanıcı. BONUS (EUR) 500
Kredi: Kullanıcı. BAHIS (EUR) 500 (bahise geçin)
Debit: Kullanıcı. BAHIS (EUR) 500
Kredi: Sağlayıcı. Yerleşim (EUR) 500 (oran kapalı yazılı)12 € kazanın. 5- NAKIT OLARAK
Debit: Sağlayıcı. Uzlaşma (EUR) 1250
Kredi: Kullanıcı. NAKIT (EUR) 1250Silme işlemini gerçekleştirme (HOLD servis hesabı aracılığıyla gerçekleştirme)
Debit: Kullanıcı. NAKIT (EUR) 500
Kredi: Kullanıcı. HOLD (EUR) 500 (hold tarafından oluşturulan)
-- anlaşmada
Debit: Kullanıcı. HOLD (EUR) 500
Kredi: Sağlayıcı. Uzlaşma (EUR) 500
-- iptal üzerine
Debit: Kullanıcı. HOLD (EUR) 500
Kredi: Kullanıcı. NAKIT (EUR) 50014) Denetim, değişmezlik ve uyumluluk
WORM/log için bağışıklık (nesne depolama/WAL arşivi).
Meta-günlüklere erişin: sınırları okuyan/değiştiren, manuel ayarlamalar yapan (yalnızca gerekçe ile "ayarlama-gönderme" yoluyla).
GDPR/düzenleyiciler: 5-10 yıl boyunca işlemlerin saklanması (yargı yetkisine göre), oyuncu için yerleşimlerin şeffaflığı (silme/bahis tarihi).
15) Hata toleransı ve DR
Multi-AZ zorunlu; Cüzdan için DR-bölgesi: bölgedeki çoğaltmayı senkronize edin, async - bölgeye; PITR etkinleştirilmiştir.
Bekleme durumunu destekleyin - yalnızca kontrol listesiyle manuel olarak (split-brain hariç).
Haftalık kontrolü geri yükle (test-geri yükleme), kontrol raporlarının miktarının mutabakatı.
16) Cüzdan gözlemlenebilirliği
SLI: 'deposit _ succcess _ ratio', 'withdraw _ success _ ratio', 'bet _ hold _ latency _ p95', 'settlement _ latency _ p95'.
Тех: 'ledger _ postings _ rate', 'db _ connections _ saturation', 'queue _ lag _ seconds', 'hold _ expired _ rate'.
Uyarılar: Piyasadaki PSP başarı düşüşü, 'hold _ expired _ rate' büyümesi, oyun sağlayıcısı senkronize değil (onay yok> N dk).
17) Test ve kalite kontrol
PSP/oyun sağlayıcıları ile sözleşme testleri (web kitapları/imzalar).
Mülke dayalı para testleri: borçların toplamı = = her Gönderimdeki kredilerin toplamı.
Fuzz/kaos: PSP/sağlayıcı gecikmeleri, webhook tekrarları, ağ flappies.
Load: seri bahisler (60-120 s), soaks (4-8 h), 'queue _ lag' kontrolü ve p99.
18) Üretime hazırlık kontrol listesi
- Çift defter girişi, 'operation _ id'ile Gönderme yoluyla yapılan tüm işlemler.
- Açık harcama politikaları ve öncelik sırası (gönderme ile devam eder).
- TTL/kısmi yerleşme/sona erme, bahis/çekilme ile iletişim ile tutar.
- Gelen Kutusu/Giden Kutusu, HMAC webhooks, tüm sınırlarda idempotency.
- Bireysel CASH/BONUS/WAGER/FS/POINTS cüzdanları; para birimlerine bölünür.
- FX ve küçük yuvarlama; Dönüşüm - ayrı bir işlem.
- Tutmak/borçlandırmak için sorumlu oyun sınırları; Denetim hatası.
- Önbelleği oku (kısa TTL) + kritik eylemlerden önce gerekli doğruluk kontrolü.
- PITR/yedeklemeler/DR komut dosyaları; Manuel teşvik, düzenli DR egzersizleri.
- Panolar/uyarılar SLI + teknik; WORM kayıtları ve erişim kayıtları.
- Yük/kaos testleri; PSP/sağlayıcıları ile mutabakat raporları.
Özgeçmiş Özeti
Çoklu cüzdan mimarisi "birçok denge numarası'değil, çift giriş, harcama politikaları, rezervasyon ve denetim ve oyuncular için şeffaf bir iz olan bir finansal sistemdir. Gerçeği günlükte tutun, tutucular ve idempotans kullanın, cüzdanları ve para birimlerini ayırın, mutabakatı otomatikleştirin ve DR. Bu şekilde cüzdan UX için hızlı, para için doğru ve en yüksek yüklere ve düzenleyici kontrollere karşı dayanıklı olacaktır.