Ბალანსი და საფულეები: მრავალფუნქციური არქიტექტურა

1) რატომ არის multi-wallet და რა მიზნები

ერთი ჩანაწერი „ბალანსი = ნომერი“ არ მოიცავს iGaming- ის რეალობას. ჩვენ გვჭირდება ცალკეული საფულეები/სუბსიდიები: რეალური ფული (cash), ბონუს საშუალებები, ვაგნერის აუზი, ფრისპინები, კომპლექტები, ზოგჯერ ვალუტის საფულეები (EUR/USD/BRL).

არქიტექტურის მიზნები:

ფულის სიზუსტე.
ჩამოწერის პოლიტიკოსები (მაგალითად, ჯერ ბონუს/wager, შემდეგ cash).
სიჩქარე (p95 API) 250-400 ms, განაკვეთი/ნაკადი რეალურ დროში).
უსაფრთხოება და შესაბამისობა (KYC/AML, საპასუხისმგებლო თამაშის შეზღუდვები, რეგულატორები).
მასშტაბი: მწვერვალები - ათობით ათასი ოპერაცია/წამი, მილიარდობით პოსტინგი/თვე.

2) მონაცემთა მოდელი: „Ledger + Subwallets“

მინიმალური არსებები

ანგარიში: მოთამაშე/ბრენდი/ბაზარი.

Wallet: `{type: CASH	BONUS	WAGER	FS	POINTS, currency, status}`.
LedgerEntry (двойная запись): `debit_account`, `credit_account`, `amount`, `currency`, `operation_id`, `category`, `created_at`.
Posting: ატომური ბიზნეს ოპერაცია, აერთიანებს 2 + LedgerEntry.
Hold/Reservation: სახსრების დროებითი დაბლოკვა განაკვეთით/დასკვნით.
პოლიტიკა: ჩამოწერის/ჩარიცხვის პრიორიტეტის წესები.
FXRate: კურსი/სიზუსტე/დამრგვალების წესები.
Limit: დღე/თვე/საპასუხისმგებლო თამაში.

ცხრილების მაგალითი (გამარტივებული)

sql
- ბალანსის ანგარიშები ორმაგი გართობისთვის (ოფიციალური ჩათვლით)
accounts(id, owner_user_id, type, currency, status,...)

- გაყვანილობა (ორმაგი ჩანაწერი, ბიზნეს ოპერაციის ბმული)
ledger_entries(id, posting_id, debit_account_id, credit_account_id,        amount_minor, currency, category, operation_id, created_at)

- Hills (რეზერვები)
holds(id, account_id, amount_minor, currency, reason, expires_at, state,    operation_id, created_at)

- ჩამოწერის პოლიტიკა (პრიორიტეტები)
spend_policies(id, market, wallet_priority jsonb, updated_at)

- ჯვარედინი ვალუტის კურსები fx _ rates (ccy _ from, ccy _ to, rate, precision, valid _ from)

წესი: ჭეშმარიტება ცხოვრობს გამტარ ჟურნალში ('ledger _ entries'). მიმდინარე ბალანსი არის ან აგრეგატი (მატერიალიზებული ფიფქია), ან გამოითვლება ჟურნალიდან (ძვირი, მაგრამ ერთადერთი მართალია).

3) საფულეების ტიპები და მათი ქცევა

საფულე	რატომ	შეგიძლიათ შეავსოთ	შეგიძლიათ ჩამოწეროთ	სპეციალური წესები
CASH	რეალური ფული	PSP/სახელმძღვანელო დარიცხვა/გადახდა	განაკვეთები, შესყიდვები, დასკვნა	გავლენას ახდენს AML/KYC- ზე; გარიგებები შედის ბუღალტრულ აღრიცხვაში
BONUS	ბონუს ფული	პრომო/კამპანიები	ფსონები (წესების მიხედვით)	იგი პირდაპირ არ არის გამოყვანილი, გადაკეთებულია Cash- ში, როდესაც ვეგერი ასრულებს
WAGER	„გაყინული“ პრემიების აღრიცხვა	პრემიისგან მიღებული მანქანა ფსონის დროს	ჩამოწერები თამაშების პროვაიდერის სასარგებლოდ	განთავისუფლების წესი settle/გაუქმებით
FS (FreeSpins)	როტაციის პაკეტები	კამპანიები	სლოტებში დაფარვა	ფულადი ეკვივალენტი ფიქსირდება T & C- ით
POINTS	ერთგულება/კომპები	აქტივობა	მაღაზია/სტატუსი	არა ფული; არ შედის AML მოხსენებებში

4) ჩამოწერის პოლიტიკა და პრიორიტეტული პროცედურა

მკაფიოდ ფორმალიზებული ალგორითმის წყარო: მაგალითი (სლოტი/კაზინო):

1. პირველი ჩამოწერილია WAGER- დან (თუ ვაგნერი აქტიურია).

2. შემდეგ BONUS- დან, ჯერ არ არის ამოწურული.

3. დარჩენილი - CASH- დან.

მაგალითი (სპორტი):

1. პირველი CASH (რეგულატორი/გადასახადი).

2. შემდეგ BONUS (freebet), თარგმნა WAGER- ში.

Postings- ში შეინარჩუნეთ „პოლიტიკის გადაწყვეტილება“, როგორც ატრიბუტი ისე, რომ sapport და აუდიტი ნახოთ „რატომ დაიწერა ასე“.

5) ფულისა და ოპერაციების სასიცოცხლო ციკლი

ანაბარი

1. 'POST/wallet/deposit' შექმნა pending ჩანაწერი (inbox კოლბეკი PSP).

2. Webhuk PSP (HMAC ხელმოწერა, 'oporation _ id' იდემპოტენტობა) - credit CaSH, category = 'DEPOSIT'.

3. ჩვენ ვაქვეყნებთ ღონისძიებას 'wallet _ განახლება'.

კურსი

1. 'POST/bet/place' - ქმნის ჰოლდს (რეზერვს) წყაროს ანგარიშზე (CASH/BONUS/WAGER).

2. განაკვეთის დადასტურებისას, hold - debit წყაროს გადაცემა, პროვაიდერის ოფიციალური „ანგარიშსწორების“ ანგარიშის კრედიტი.

3. გაუქმებისას - release hold.

Settlent (შედეგი)

მოგება: „ანგარიშსწორების“ პროვაიდერის ანგარიში - credit CASH ან WAGER - BONUS - CASH პოლიტიკის შესახებ.

დანაკარგი: ჩვენ ვხურავთ მიმწოდებლის „მოხმარება“ მოთამაშეს სესხების გარეშე.

1. KYC/AML შემოწმება, საპასუხისმგებლო თამაშის ლიმიტები.

2. Hold დასკვნის ოდენობით.

3. PSP- ის წარმატება არის საბოლოო debit CASH - credit ანგარიში „გადახდა“.

4. PSP უკმარისობა.

6) Idempotence და exactly-once „მნიშვნელობით“

ყველგან 'operation _ id' (UUID/გაუმჯობესებული ULID) უნიკალური ინდექსით. მეორე მოთხოვნა არის წარსული ოპერაციის სტატუსი.

ვებჰუკი PSP/თამაშების პროვაიდერი: Inbox მაგიდა dedupe 'event _ id + signature'. დამუშავება - იდემპოტენტური ვორკერი (Outbox პატრონი).

Idempotency-Key კლიენტისთვის HTTP; TTL შენახვა 24-72 საათზე.

7) რეზერვები და ყინულები

ჰოლდი არ არის ჩამოწერილი, არამედ ხელმისაწვდომი ნარჩენების „გაყინვა“.

წესები:

გორაკის სიცოცხლის ხანგრძლივობა: seconds - minutes (კურსი) ან საათი (გამომავალი).
Hill შეიძლება ნაწილობრივ ან მთლიანად დაფაროს (ნაწილობრივი settle).
Expire - ავტომატური release და მოვლენა.
შეინახეთ კავშირი 'hold _ id' '' bet _ id/withdraw _ id '.

8) ვალუტა, FX და დამრგვალება

ფულადი თანხები - მცირე ერთეულებში (ცენტები), ტიპი - მთელი.

დამრგვალებული საბანკო (დამრგვალება) ან T & C.

FX: 'CASH (EUR)' CASH (აშშ დოლარი) 'უმჯობესია საფულეების გაყოფა. კონვერტაციის გაკეთება, როგორც ცალკეული ოპერაცია:

'debit EUR, credit FX _ EURURUSD' და 'debit FX _ EURURUSD, credit აშშ დოლარი' - გამჭვირვალეა აუდიტისთვის.
აკრძალულია დავის დროს კურსის „მიღწევა“ ავტომატურად; ყველა წესი არის FX პოლიტიკაში.

9) პასუხისმგებელი თამაში და შეზღუდვები

Deposit/Bet/Loss/Session limites (დღე/კვირა/თვე), „cooling-off“, self-exclusion.

ხორციელდება როგორც წინასწარი შემოწმება hold/debit- ის წინ.

უარის თქმის ლოგოები - ცალკეული აუდიტის ჟურნალი, ხელმისაწვდომია საფოსტო და რეგულატორისთვის.

10) საფულის გარშემო ანტიფროდიული სიგნალები

მოწყობილობების მტევანი/ASN, მცირე თანხის ხშირი დეპოზიტები - დიდი დასკვნები, სარეცხი ნიმუშები.

Velocity ლიმიტები 'deposit/withdraw' მიხედვით BIN/ქვეყანა/მოწყობილობა.

ბლოკის ფურცლები მიმღებისთვის (საფულეები/IBAN), „ჯორკების“ სია.

საფულის მოვლენები feature store- ში (ლოგინი/ანაბრები/განაკვეთი).

11) კომპოზიცია და შესრულება

ჭეშმარიტება ქეში

ჭეშმარიტება - ლედგერში. API- სთვის „ბალანსის მოპოვება“ - შეინარჩუნეთ მატერიალური სროლა ('user _ id + wallet _ type, balance _ minor, ვერსია').

წერა: მონაცემთა ბაზაში გარიგება ქეშის ინვალიდობას იწყებს.

„მძიმე“ flow (live) არის შესაფერისი მოკლე TTL 1-5, + ჭეშმარიტების სავალდებულო შემოწმება დაწყებამდე/დიდი კურსით.

ჩამოტვირთვა

შარდვა 'user _ id' (მოდული/რანჟირება), ცალკეული შარდმდენი აუზები CASH vs BONUS- ის ქვეშ.

ცხელი გასაღებები (VIP/ბოტები) - request coalescing 'user _ id'.

ასინქრონული აგრეგაციები (ჩამოაყალიბეთ 'posting' - ის „snapshot-apdater“ ფონზე).

12) API კონტრაქტები (ფსევდო)

ბალანსი

http
GET /v1/wallets? types=CASH,BONUS
→ 200 {"wallets":[
{"type":"CASH","currency":"EUR","available":12050,"hold":500,"version":1942},  {"type":"BONUS","currency":"EUR","available":3000,"wager_req":15000}
]}

ფსონი (ჰოლდთან)

http
POST /v1/bets/place
{"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}

Settlent

http
POST /v1/bets/settle
{"bet_id":"b_123","result":"WIN","payout":1250}
→ 200 {"status":"SETTLED","cash_delta":+1250}

http
POST /v1/withdrawals
{"withdraw_id":"w_456","amount":10000,"currency":"EUR","method":"sepa", "idempotency_key":"ik_def"}
→ 202 {"state":"PENDING","next_check_sec":2,"status_url":"/v1/withdrawals/w_456"}

13) გაყვანილობის მაგალითები

ანაბარი - 100 (PSP fee - 1, commis. ანგარიში - ცალკე)


Debit: PSP_Settlements(EUR)   10000
Credit: User. CASH(EUR)         10000

Debit: User. CASH (EUR) 100 (ჩვენ გადავდივართ)
Credit: PSP_Fees(EUR)          100

კურსი - 5 BONUS- დან (თარგმანი WAGER- ში)


Debit: User. BONUS(EUR)       500
Credit: User. WAGER (EUR) 500 (გადაადგილება Wager)
Debit: User. WAGER(EUR)       500
Credit: Provider. Settlement (EUR) 500 (განაკვეთი დაიშალა)

მოგება - 12. 5-ში CASH- ში


Debit: Provider. Settlement(EUR)  1250
Credit: User. CASH(EUR)         1250

ჰოლდინგის ჩამოწერა (განხორციელება HOLD ოფიციალური ანგარიშის საშუალებით)


Debit: User. CASH(EUR)       500
Credit: User. HOLD (EUR) 500 (შეიქმნა ჰოლდი)
- settle- ზე
Debit: User. HOLD(EUR)       500
Credit: Provider. Settlement(EUR)   500
- გაუქმებისას
Debit: User. HOLD(EUR)       500
Credit: User. CASH(EUR)         500

14) აუდიტი, უცვლელი და შესაბამისობა

WORM/immutability ჟურნალისთვის (ობიექტის საცავი/WAL არქივი).

წვდომის მეტაჟურნალები: ვინც წაიკითხა/შეცვალა ლიმიტები, ვინც სახელმძღვანელო კორექტირება მოახდინა (მხოლოდ დასაბუთებით „adjustment-posting“ საშუალებით).

GDPR/რეგულატორები: გარიგების შენახვა 5-10 წლის განმავლობაში (იურისდიქციის შესაბამისად), მოთამაშისთვის გამოთვლების გამჭვირვალობა (ჩამოწერის ისტორია/ვეგერი).

15) წინააღმდეგობა და DR

Multi-AZ აუცილებელია; საფულისთვის DR რეგიონი: ზონაში sync რეპლიკაცია, async - რეგიონში; PITR ჩართულია.

Promote standby - მხოლოდ ხელით ჩეკის ფურცელზე (გამორიცხულია split-brain).

აღდგენა შეამოწმეთ ყოველკვირეულად (ტესტირება), თანხის გადამოწმება საკონტროლო ანგარიშებზე.

16) საფულის დაკვირვება

SLI: `deposit_success_ratio`, `withdraw_success_ratio`, `bet_hold_latency_p95`, `settlement_latency_p95`.

Тех: `ledger_postings_rate`, `db_connections_saturation`, `queue_lag_seconds`, `hold_expired_rate`.

ალერტები: success PSP- ის ვარდნა ბაზარზე, ზრდა „hold _ expired _ rate“, თამაშების პროვაიდერის რასინქრონი (არ არსებობს მტკიცებულება> N წთ).

17) ტესტირება და ხარისხის კონტროლი

ხელშეკრულების ტესტები PSP/თამაშის პროვაიდერებით (ვებჰუკები/ხელმოწერები).

Property-based ფულის ტესტები: დებატების ჯამი = = სესხების ოდენობა თითოეულ პოსტინგში.

Fuzz/chaos: PSP/პროვაიდერის შეფერხებები, ვებჰუკების გამეორება, ქსელის ფლოპი.

დატვირთვა: burst განაკვეთები (60-120 გვ), soaks (4-8 საათი), კონტროლი 'queue _ lag' და p99.

18) წარმოების სიის მზადყოფნა

ორმაგი ჩანაწერი ledger, ყველა ოპერაცია Posting მეშვეობით 'operation _ id'.
მკაფიო პოლიცია და პრიორიტეტული წესრიგი (პერსონაჟი პოსტინგთან ერთად).
Hills ერთად TTL/partial settle/expiry, კავშირი bet/withdraw.
Inbox/Outbox, HMAC ვებჰუკი, იდემპოტენტობა ყველა საზღვარზე.
ცალკეული CASH/BONUS/WAGER/FS/POINTS საფულეები; ვალუტის დაყოფა.
FX და დამრგვალება უმცირესობათა ერთეულებში; კონვერტაცია ცალკე ოპერაციაა.
საპასუხისმგებლო თამაშის ლიმიტები hold/debit; უარის თქმის აუდიტი.
კითხვის ქეში (მოკლე TTL) + ჭეშმარიტების სავალდებულო შემოწმება კრიტიკულ ქმედებებამდე.
PITR/bacaps/DR სკრიპტები; სახელმძღვანელო promote, რეგულარული DR სწავლებები.
დაშბორდი/ალერტები SLI + ტექნიკური; logs WORM და წვდომის მეტაჟურნალები.
დატვირთვა/ქაოსის ტესტები; ჩანაწერების მოხსენებები PSP/პროვაიდერებთან.

რეზიუმე

Multi-wallet- ის არქიტექტურა არ არის „ბევრი ბალანსი“, არამედ ფინანსური სისტემა ორმაგი ჩანაწერით, ხარჯვის პოლიტიკოსებით, რეზერვაციით და გამჭვირვალე კვალი აუდიტის და მოთამაშეებისთვის. შეინარჩუნეთ სიმართლე ჟურნალში, გამოიყენეთ ჰოლდინგები და idempotence, გაზიარეთ საფულეები და ვალუტები, ავტომატიზაცია მოახდინეთ ჩანაწერების და DR- სთვის. ასე რომ, საფულე სწრაფი იქნება UX- სთვის, ფულის ზუსტი და სტაბილური პიკის დატვირთვისთვის და მარეგულირებელი შემოწმებისთვის.