Კაზინოს მრავალ ბრენდის არქიტექტურა: ზოგადი მომსახურება და იზოლაცია

სტატიის სრული ტექსტი

💡 18+. საგანმანათლებლო მასალა. არა თამაშის მოწოდება. ფოკუსი - ინჟინერიასა და iGaming პლატფორმების შესაბამისობაზე.

1) მრავალ ბრენდის პლატფორმის ამოცანა

ერთი ტექნოლოგიური „ჩონჩხი“ ემსახურება რამდენიმე ბრენდს/ლიცენზიას/გეოს. მიზანია ბირთვის მაქსიმალური გადახრა (სიჩქარე, ღირებულება) რისკებისა და მონაცემების მკაცრი იზოლაციით (ფული, PII, მოხსენება).

საკვანძო არჩევანი: multi-tenant (ზოგადი ინსტანციები, ერთი სერვისის „მოიჯარე“) ან მრავალჯერადი ინსტანცია (ცალკეული ინსტანციები/BD/მტევანი ბრენდის ან რეგიონის მიმართ). პრაქტიკაში გამოიყენება ჰიბრიდი.

2) ფენები და საზღვრები (საცნობარო სქემა)

Edge / Governance

API-gateway, WAF/bot დაცვა, გეო ფილტრები, ტარიფები, მომსახურება.

Tenant/brand resolver: ბრენდის მეტამონაცემები (ლიცენზია, გეო, ვალუტა, დროშები).

დომენის Core (მომსახურებით)

PAM (ანგარიშები, სესიები, 2FA) - მულტი-ტენანტი, ტენანტის _ id ხისტი განცალკევებით.

Wallet/Ledger (ბუღალტრული აღრიცხვა) - უფრო ხშირად მრავალჯერადი ინსტანციის პერ ლიქენსი/რეგულირება.

Cashier/PSP Orchestration - ბრენდის/რეგიონის ცალკეული plines/გასაღებები.

KYC/AML - geo დაკავშირებული პროვაიდერები, წესები ჩრდილის დონეზე.

Bonus Engine/Tournaments/Jackpots - shareable მომსახურება წესების იზოლაციით.

Game Gateway არის ზოგადი კარიბჭე პროვაიდერებისთვის, რომლებსაც აქვთ ბრენდის სრული/ვალუტა.

Affiliates/Commission - ზოგადი მათემატიკა, ცალკეული სავაჭრო ადგილები.

RG - ლიმიტები და სტატუსები ბრენდის/იურისდიქციის დონეზე, სინქრონული გაჩერების სიგნალები.

Compliance/Reporting - ვიტრაჟები და გადმოტვირთვები ბრენდზე/ლიცენზიაზე/რეგიონში.

CMS/Front არის ზოგადი ინსტრუმენტები + per-brand თემები/ნავიგაცია.

Data & Observability

მოვლენების ავტობუსი (Kafka/Pulsar) 'tenant _ id/brand _ id' კლავიშებით.

OLTP მომსახურებისთვის, OLAP ფანჯრები, რომელსაც აქვს მკაცრი row-level იზოლაცია ბრენდის მიხედვით.

მეტრიკი/ტრეისი/ლოგები სავალდებულო ტენანტის ჭდეებით; SIEM/SOAR.

3) სად გავუზიაროთ და სად გამოვყოთ?

3. 1 ზოგადი მომსახურება (დაზოგვა და სიჩქარე)

Game Gateway: ერთიანი ინტეგრაცია სტუდიებთან, წინა ბრენდის წინა დროშები.

Bonus/Tournament Engine: საერთო დიზაინერი, მაგრამ „ქვიშის ყუთები“ და per brand ლიმიტები.

Affiliates/Tracking: ერთიანი პლატფორმა, ცალკეული SAB-ID/დომენები/პოსტბეკები.

KYC/Screening Orchestrator: ზოგადი საბურავი, გეოს სხვადასხვა პროვაიდერები.

CMS/Front toolkit: თემები/ლოკალიზაცია/ვიჯეტები; ფრონტის გამონაყარი ბირთვისგან დამოუკიდებლად.

BI/ETL: ზოგადი პაკეტები, ინდივიდუალური ფანჯრები და უფლებები.

3. 2 მკაცრი იზოლაცია (ფული, კანონი, პირადი მონაცემები)

Ledger/Wallet: ცალკეული BD/ინსტანციები ლიცენზიის/რეგიონისთვის (ხშირად ცალკეული კლასტერიც კი).

Cashier/PSP: გასაღებები, მერჩანტები, მარშრუტიზაცია და წინა ბრენდის/რეგიონის ლიმიტები.

PII/რეზიდენტობა: მომხმარებელთა მონაცემები ინახება რეგიონში; ჯვარედინი რეგიონალური მოთხოვნების აკრძალვა.

Compliance/Reporting: მარეგულირებელი გადმოტვირთვები მკაცრად ბრენდის/ლიცენზიის მიხედვით.

RG/AML: გაჩერების სიგნალები გამოიყენება „ადგილზე“, ტენანტური ბურთის გარეშე.

4) მონაცემთა მულტფილმის მოდელები

1. Schema-per-tenant: ერთი BD, ცალკეული სქემები. უბრალოდ დაწყება, უფრო რთულია მასშტაბის გაკეთება.

2. DB-per-tenant: ბრენდის/რეგიონის ცალკეული DD (ან მტევანი). უფრო ძვირი, მაგრამ უსაფრთხო.

3. Table-partitioning by tenant: დიდი ცხრილი მძიმე RLS/შენიღბვით; შესაფერისია ტელემეტრიისთვის/ლოგებისთვის.

4. Storage-per-jurisdiction: ფიზიკური რეზიდენცია (EU, დიდი ბრიტანეთი, BR...), რეგიონთაშორისი წვდომა აკრძალულია ქსელებზე/ACL.

ლედგერისთვის, ჩვეულებრივ, არჩეულია DB-per-license/region + ცალკეული მომსახურების ფენა.

5) ფულადი წრე: ინვარიანტები და მოვლენები

ბრძანებების ატომურობა და იდემპოტენტურობა ('wallet. debit/credit/settle ') არის საკვანძო კონტრაქტი.

Outbox/CDC: მოვლენების გამოქვეყნება გარიგების სინქრონული; არა „სახელმძღვანელო მაგია“.

საგები: ანაბარი/ქეშაუთი/პრემია - მხოლოდ ორკესტრის საშუალებით, ცალკეული მოვლენების ანაზღაურება.

ცალკეული ჯეკპოტის საფულეები და გამჭვირვალე წინა ბრენდის/აუზების შენატანები.

SLO ბირთვისთვის (მინიმალური):

p95 საფულე <150 ms; დაკარგული/დუბლირებული ნაკრები = 0.
Cashier ავტორიზაცია <3 გვ; ანაბრის წარმატებამ 85% შეადგინა სამიზნე გეოზე.
ღონისძიებების მიწოდება BI-5 წუთში.

6) გადახდის ორკესტრი მრავალ ბრენდის შემადგენლობაში

Pipline per brand/barket: სხვადასხვა PSP, marshants, limites, 3-DS პოლიტიკა.

კასკადი: fallback- ის უკმარისობა კალათის დაკარგვის გარეშე.

FinOps: მარშრუტები ღირებულებით/კონვერტაციით; ყოველდღიურად ბრენდების კრიკეტების მოხსენებები.

Anti frode: velocity, გრაფიკული რუქა/მოწყობილობები ბრენდის შიგნით და ჰოლდინგში (ფრთხილი ჯვარედინი კორელაციით).

7) პასუხისმგებელი თამაში და შესაბამისობა

RG ლიმიტები (ანაბრები/დანაკარგები/დრო/განაკვეთი) - კონფიგურირებულია per brand/იურისდიქცია, ისინი სინქრონულად გამოიყენება განაკვეთზე.

თვითგამორკვევა და ჩეკების რეალობა პატივს სცემს ბრენდის საზღვრებს და რეგიონის კანონს.

AML/KYC - სანქციები/REP/სახსრების წყარო; SAR/STR ბრენდის მიხედვით.

მოხსენება - ავტომატიზირებული; სახელმძღვანელო Excel აკრძალულია როგორც პროცესი.

8) დაკვირვება და წვდომა

Trace-ID გადის + ჭდეები 'tenant _ id/brand _ id/license'.

RBAC/ABAC: „ფინანსები/რისკი/საფოსტო/მარკეტინგი/შესაბამისობა“ როლები მხოლოდ მის ბრენდზე წვდომაა.

Audit WORM: საკრუიზო მოქმედებების უცვლელი ლოგოები, „ოთხი თვალის“ პოლიტიკა.

საიდუმლოებები/გასაღებები: Vault/HSM, ბრენდის/რეგიონის გასაღებების სეგმენტი, როტაცია.

9) ტოპოლოგია

Single Cluster, Multi-Tenant Services

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

Regional Clusters + Shared Integrations

სათამაშო კარიბჭე და ზოგადი სერვისების ნაწილი ირეცხება, ფული/PII - რეგიონალურად. ღირებულებისა და შესაბამისობის ბალანსი.

Per-Brand/License Stacks

სრული იზოლაცია (VIP ბრენდები, მაღალი რისკები). ძვირია, მაგრამ მინიმალური blast radius.

ხშირად შერწყმულია: ინტეგრაციისა და ინსტრუმენტების ზოგადი „ფენა“ + იზოლირებული ფული/PII.

10) მონაცემებისა და კატალოგების შესახებ

Data contracts: Avro/JSON Schema + Registry; სემანტიკური ვერსიები.

მთავრობის: ველების კატალოგი, მეპატრონეები, SLA ფანჯარა, წარმოშობის ხაზი (ხაზის).

RLS/Masking: წესები შენახვის დონეზე და BI; PII- ზე წვდომა - განაცხადისა და დროის ნიშნის მიხედვით.

გვიან arrivals/dedup: სტაბილური ნიმუშები OLAP- ში.

11) მარკეტინგი, CMS და აფილიატები

Feature Flags per brand: სარეკლამო/თემების/მექანიკის წარმოება ჯვარედინი ეფექტების გარეშე.

შინაარსის კატალოგები: პროვაიდერების/თამაშების ერთიანი ID, ბრენდის/ბაზარზე წვდომის შემცირება.

აფილატები: ცალკეული დომენები/UTM/sab-ID; ანტი-ფროიდი ქვე პარტნიორებისთვის.

პლატფორმების დაცვა (YouTube/Twitch): რეკლამირების ეტიკეტირება/per brand affiliats.

12) მრავალ ბრენდის არქიტექტურის სიმწიფის მეტრიკა

1. ფულის იზოლაცია: ცალკეული BD/ინსტანციები ლიცენზიის/რეგიონისთვის; ნულოვანი სახელმძღვანელო კორექტირება.

2. მონაცემთა აღდგენა: ტექნიკურად უზრუნველყოფილია (ACL/ქსელის პოლიტიკა), რომელიც შემოწმებულია სავარჯიშოებით.

3. ღონისძიება: outbox/CDC ყველგან; ნაკადები BI-5 წუთს აღწევს.

4. გადახდები: PSP კასკადი აქტიურია; კრიკეტების მოხსენებები ავტომატიზებულია.

5. RG/AML: გაჩერების სიგნალები გამოიყენება სინქრონულად; ანგარიში სახელმძღვანელო ნაბიჯების გარეშე.

6. Observability: ყველა მეტრიკა/ლოგო/ტრეისი აღინიშნება brand/tenant; SLO Dashbords სერვისები და ბრენდები.

7. წვდომა: RBAC/ABAC და „ოთხი თვალი“ კრეტაზე ოპერაციებზე, WORM აუდიტზე.

8. DR გეგმა: RPO - 5 წთ, RTO - 30 წთ; რეგულარული წვრთნები თითოეული რეგიონისთვის.

13) არქიტექტორის ჩეკის სია (ბრენდის დაწყებამდე)

ენიჭება 'brand _ id/tenant _ id', გაიხსნა გასაღებები/საიდუმლოებები და შეზღუდვები.
Ledger/Wallet - გამოყოფილი BD/კასეტა (ლიცენზიის საჭიროების შემთხვევაში).
კაშიერი - საძაგელი ანგარიშები და მარშრუტები; ტესტის გარიგებები და შემოწმება.
RG/AML/KYC - პროვაიდერები, წესები, გაჩერების სიგნალები; ტესტის სცენარები.
Game Gateway - პროვაიდერების/ვალუტების/შეზღუდვების მაპინგი; ჯანმრთელობის შემოწმება.
Bonus/Tournament - ქვიშის ყუთი და წესების აუდიტი.
Affiliates - sab სივრცე, postbeks, anti frode.
CMS/Front - თემა, ლოკალიზაცია, ფიჩფლაგები; გეო შეზღუდვების შემოწმება.
BI/Reports - ფანჯრები, წვდომა, მარეგულირებელი გადმოტვირთვები.
დაკვირვება - SLO დაშბორდები და ბრენდის/რეგიონის ალერტები.

14) წითელი დროშები (რომელიც არღვევს მრავალ ბრენდს)

ერთიანი BD „ყველასთვის“ RLS/შენიღბვის გარეშე და ცალკეული Ledger- ის გარეშე.

ბალანსების, პრემიებისა და ლიმიტების ხელით რედაქტირება.

PSP- ის ზოგადი სავაჭრო გასაღებები სხვადასხვა ბრენდისთვის/რეგიონისთვის.

მოვლენების გამოქვეყნება დომენის გარიგების „წარსულში“ (არ არსებობს გარე/CDC).

BI/მოხსენებები საბრძოლო OLTP ცხრილებზე.

PII და DR ვარჯიშების გეო იზოლაციის არარსებობა.

RG/AML წესები შეირყა ბრენდებს შორის ადგილობრივი კანონის გათვალისწინების გარეშე.

არ არსებობს ჩრდილის/ბრენდის ტეგები ლოგებსა და მეტრიკებში - გამოძიება ქაოსად იქცევა.

15) შედეგი

მრავალ ბრენდის არქიტექტურა არის საერთო და გამოყოფილი ბალანსი. ზოგადი ინტეგრაცია, ინსტრუმენტები და მოვლენები აჩქარებს განვითარებას; იზოლირებული ფული, გადასახადები, PII და ანგარიშგებები ინარჩუნებს შესაბამისობას და ამცირებს რისკებს. წარმატებული პლატფორმა აგებულია სამი პრინციპის გარშემო:

1. ფულადი მთლიანობა და იზოლაცია (Ledger/Cashier per license/region, idempotence, sagi).

2. ღონისძიება და დაკვირვება (საბურავი, კონტრაქტები, ბრენდის/ტენანტის ჭდეები, SLO).

3. იურიდიული რეზიდენცია და წვდომა მინიმუმამდე (RBAC/ABAC, WORM აუდიტი, KMS/Vault).

ასეთი საფუძველი საშუალებას გაძლევთ შეაფასოთ ბრენდების პორტფელი სირთულის ექსპონენციალური ზრდის გარეშე - სწრაფი, უსაფრთხო და პროგნოზირებადი.