Arhitectura de bază a cazinoului: straturi, module, autobuze de date

Articol complet

💡 18+. Materialul este educativ. Nu este un apel pentru a juca. Scopul este de a arăta o „hartă de teren” de inginerie pentru construirea sau auditarea miezului iGaming.

1) Întreaga imagine: ce nucleu de cazino este format din

Casino core este un set de servicii de domeniu care oferă înregistrarea/identificarea jucătorilor, acceptarea/stocarea banilor, calcularea pariurilor, economia bonusului, controlul riscurilor și respectarea reglementărilor. În diagrama de sus în jos:

1. Strat de margine (perimetrul exterior): gateway-ul API, protecție WAF/bot, limitarea ratei, pătrunderea mesh-ului de serviciu, filtre geo/legale.

2. Domain- слой (бизнес - логика): PAM, Portofel/Ledger, Motor bonus, Casier/PSP Orchestrație, Sesiuni de joc, Risc/Antifraudă, RG, Jackpot/Turnee, Afiliați, CRM/Notificări, Conformitate/Raportare.

3. Date/strat de integrare: autobuze de evenimente (Kafka/Pulsar), cozi (SQS/Iepure), CDC/Outbox, ETL/ELT (în vitrine BI), Feature Store/ML, cache-uri (Redis), OLTP DB (Postgres/Oracle), OLAP (ClickHouse/BigQuery).

4. Observabilitate și SecOps: metrici/urmărire/busteni, SIEM/SOAR, secrete (Vault/HSM), chei și jetoane, RBAC/ABAC, jurnal de audit (WORM).

2) Module de domeniu (compoziția minimă necesară)

2. 1 PAM (Player Account Management)

Înregistrare/autentificare, SSO, gestionarea sesiunilor și a dispozitivelor, KBA/2FA.

Profil: vârstă/geo/valută/segmente, RG/statusuri de autoexcludere.

Restricții: accesul la jocuri în funcție de jurisdicție, interdicții, „verificarea realității”.

2. 2 portofel/registru (circuit de bani)

Conturi multicurrency, intrare dublă (debit/credit), tranzacții imuabile.

Pariuri atomice și tranzacții câștigătoare (chei de idempotență, exact o dată într-un domeniu).

Deține în spatele activ/runde; conturi de tranzit jackpot.

Interacțiune numai prin comenzi (API comandă), citire - prin proiecții (CQRS).

2. 3 Casier/Orchestrație PSP

Rutarea plăților prin benzi geo/bin/scoring; cascadă în caz de eșecuri.

3-DS/AVS/velocity-rules; tokenizarea cardurilor; pe/off-rampă pentru criptă.

Set SLO: autorizare ≤ 3c p95, succes total depozit ≥ 85% geo.

2. 4 Sesiuni de joc (integrări ISP)

Crearea de sesiuni de joc (strângere de mână token), validarea țării/monedei/vârstei.

stavka→iskhod→settlment evenimente merg în autobuz; RNG și decontarea sunt de partea furnizorului.

Anti-abuz: pariul min, frecvența de rotire, interzicerea schimbării valorii nominale „în interiorul trucului”.

2. 5 Bonus Motor

Stări bonus (emise/blocate/active/pierdute), vager, contribuție la joc, pariu maxim/max cashout, termene limită.

Misiuni/misiuni, freespins, cashback; compatibilitate turneu/jackpot.

Valabilitatea strictă a regulilor la momentul pariului; istorie de neschimbat.

2. 6 Risc/Antifraudă

Indicii comportamentale (rata de miză, conturi multiple, dispozitive/carduri partajate).

Reguli de viteză, verificări grafice ale conexiunilor, apărare chargeback.

reacţii: moale (limite), greu (bloc/escaladare în LMA).

2. 7 Joc Responsabil (RG)

Depozit/pierdere/pariu/limite de timp, timeout-uri, auto-excludere.

„Verificarea realității” și pauze forțate; depozitarea consimțământului și a jurnalelor.

2. 8 Jackpot-uri și turnee

Local/rețea, fix/progresiv; taxa de partajare cu fiecare rată.

Clasamente publice; verificarea independentă a rezultatelor; anti-bot.

2. 9 Afiliați și CRM

Sub-ID de urmărire, atribuire (CPA/RevShare/Hybrid), post-spate.

Segmentare, declanșatoare, reguli de suprimare, omnichannel (push/e-mail/SMS).

2. 10 Conformitate și raportare

Compensări de reglementare, rapoarte fiscale, SAR/STR; Jurnal de audit WORM.

Rezidența datelor în funcție de jurisdicție (EU/UK/BR etc.).

3) Modelul evenimentului și autobuzele de date

3. 1 Subiecte de bază (exemplu de denumire Kafka)

"jucator. înregistrat „,” jucător. kyc. status. changed '

"umed. debit. solicitat/comis/eșuat „,” portofel. credite ".

'game. sesiune. început/încheiat „,” pariu. plasat „,” pariu. settled '

"bonus. emis/consumat/pierdut „,” pariu. progrese. actualizated '
"rg. limită. hit ',' rg. timeout. start/ended '
casier. depozit. a solicitat/a reușit/a eșuat „,” retragere. required/sentinţă "
"risk. alertă. ridicat/închis „,” aml. caz. opened '
jackpot. contribuție/declanșat „,” turneu. scor. actualizated '

Contracte: Avro/JSON Schema + Schema Registry, versioning (compatibil înapoi), taste stricte idempotence.

3. 2 Șablon de eveniment (simplificat)

json
{
„ :” uuid „,” : „bet. settled”, „ :”  „” : „brand-1”, „ ”: „ ”: „sarcină utilă”: {
„game_id": „provider:slot_777,” „bet_amount": {„cantitate”: 2. 00, "valută": "EUR"} ", win_amount": {"sumă": 36. 40, "monedă": "EUR"} ", bonus_impacted": adevărat
}
}

Regula: evenimentele sunt imuabile; ajustări - prin evenimente compensatorii separate.

3. 3 Outbox & CDC

Toate tranzacțiile de domeniu scriu un eveniment în outbox în aceeași bază de date → editorul de fundal îl trimite la autobuz.

CDC (Debezium și analogi) - pentru fluxurile secundare în DWH fără sarcină pe OLTP.

4) Coerență, saga și idempotență

Sagas pentru procese lungi (depozit/cashout, verificare, premii de turneu).

Idempotența tuturor comenzilor este 'Idempotency-Key' + deduplicarea service-side.

Strategia de coerență: în portofel - strict (ACID), altfel - eventual (prin proiecții).

Compensații: evenimente individuale de domeniu, interzicerea „editărilor manuale” în registru.

5) Date: OLTP/OLAP, cache-uri, proiecții

OLTP: Postgres/Oracle pentru portofel, PAM, bonusuri (p95 <150ms).

Cache: Redis pentru sesiuni, limite, proiecții fierbinți ale clasamentelor.

OLAP: ClickHouse/BigQuery - витрины KPI (FTD, NGR, ARPPU, Retention, LTV, Progresul pariurilor, Steaguri de risc).

Proiecții (CQRS): căutare rapidă de jucători/tranzacții (<2c), panou RG în timp real/risc.

6) Orchestrarea plăților: mai detaliate

Reguli de rutare: geo, BIN, rata de risc, încărcare, cost.

Cascadă: PSP1 → PSP2 fără a pierde coșul; se retrage cu pauză exponențială.

Reconcilieri: rapoarte PSP zilnice → registru portofel; discrepanțe auto → bilete.

7) Integrarea cu furnizorii de jocuri

Gateway model: un singur joc API, monedă/caracteristică de cartografiere, verificarea de sănătate cu degradare.

Decontare: furnizorul de intrare collback → comanda de domeniu portofel. soluționați cu cheia de idempotență.

Interblocări: minime; pariu/câștig - pereche atomică de tranzacții.

8) Observabilitate și SLO

Метрики: p95/p99 latență per serviciu, rată de eroare, saturație, KPI-uri de afaceri (pariuri/min, decontare lag, succes depozit).

Trace trace_id end-to-end (edge→domeny→shina→konsyumery).

Jurnale: structurat, cu editare PII.

Minimum SLO:

Durata de funcţionare ≥ 99. 95%
p95 portofel <150 ms
Așezări pierdute/duplicate = 0
Timp de întârziere a evenimentului la BI <5 min

9) Siguranță și conformitate

Zero-trust: mTLS în interiorul ochiurilor de plasă, jetoane de scurtă durată, RBAC/ABAC, principiul cel mai puțin drepturi.

Secrete: Vault/HSM, rotație cheie, criptare date KMS „în repaus”.

PCI DSS/GDPR/analogi locali: segmentarea mediilor, tokenizarea PAN, DLP, jurnalul de acces (WORM).

Protecție WAF/bot: filtre pe semnale comportamentale, amprentarea dispozitivului.

Rezidența datelor: timiditate pe regiuni; interdicția PII transregională.

10) Disponibilitate, DR și versiunea de lansare

Activ-activ/activ-pasiv pe regiuni; RPO ≤ 5 min, RTO ≤ 30 min.

Canare/feature-steaguri, rollback-uri; migrări de baze de date - prin intermediul unor indici fantomă/secundari.

Ingineria haosului: fișiere regulate de rețea/PSP/furnizor pentru a verifica degradarea.

11) Schema și managementul calității datelor

Contracte de date: event versioning (semver), testele contractelor de producător/consumator.

Guvernanță: catalog de date, nivel de încredere sursă, actualizare storefront SLA.

Calitate: eliminare a duplicatelor, sosiri târzii, supărări idempotente în OLAP.

12) Roluri și acces (Back-office)

RBAC: roluri clare (finanțe, risc, sprijin, marketing, conformitate).

Acțiuni Creta: confirmări ale „4 ochi”, un jurnal de operațiuni neschimbabile.

ecran PII: mascare; acces complet - prin cerere/jetoane temporare.

13) Valorile maturității de bază a cazinoului (stima de sine)

1. Fiabilitate: portofelul/casa de marcat/SLO-urile de sesiune sunt efectuate ≥ 99% din zile.

2. Date: evenimentele au lovit BI ≤ 5 min; registre de consistență vs PSP ≥ 99. 99%.

3. Bonusuri: designer de reguli fără modificări de baze de date; auditul modificărilor.

4. RG/AML: semnale în timp real; rapoartele/încărcările sunt automatizate.

5. Incidente: MTTR <30 min; postmortems sunt publice pe plan intern.

6. Testare: contract, încărcare, teste de haos; furnizor/cutii de testare PSP.

14) Lista de verificare a auditorului de arhitectură

Există un outbox/CDC, evenimentul este publicat atomic cu tranzacția.
Registrul este implementat ca o carte de postare imuabilă; există o reconciliere cu PSP.
Toate comenzile sunt idempotente; există o eliminare cheie a duplicatelor.
Separarea OLTP și OLAP; proiecțiile nu lovesc bazele de date de luptă.
Limitele RG sunt aplicate sincron la rata; verificarea realității este aplicată.
Gateway-ul jocului se degradează pentru a citi-numai/” fără sesiuni noi” în incidente.
Planul DR este exercitat în mod regulat; copii de rezervă sunt verificate de recuperare.
Politica cheie/secretă și rotația este documentată.
Rapoartele de conformitate sunt colectate automat (fără lucrul manual Excel).
Jurnalele de audit - WORM, cel mai mic acces la drepturi.

15) Anti-modele („steaguri roșii”)

Modificări manuale de solduri și bonusuri în baza de date.

Amestecarea API-ului public și privat, lipsa gateway-ului API.

Înregistrarea evenimentelor „ocolirea” tranzacțiilor de domeniu (nu prin outbox).

Portofel monolit și bonusuri fără idempotență și saga.

Baza de date unificată „pentru tot” + cererile BI în conformitate cu schema de luptă.

Lipsa versionării evenimentelor și a testelor contractuale.

Nu există nici un registru de modificări ale regulilor de bonus și formulele de turneu.

Eșecuri de plată fără cascadă; „încearcă mai târziu” ca strategie.

Nu există instrumente RG din cutie; licenţă pentru trusturi.

Casino core este un eveniment bazat pe, strict limitat de drepturi „rețea” de servicii în cazul în care banii și responsabilitatea sunt primare. Arhitectura puternică se bazează pe trei piloni:

1. Integritatea greu de bani (registru, idempotence, sagas, outbox/CDC), 2. Eveniment și observabilitate (contracte, urmărire, SLO, vitrine BI), 3. Securitate și conformitate implicite (zero-trust, PCI/GDPR, RG/AML).

După ce a construit aceste fundații, operatorul scalează conținutul, economia bonusului și marketingul fără riscuri la principalul lucru - banii jucătorilor și reputația brandului.