Cum funcționează arhitectura backend-ului cazinoului

1) Întreaga imagine: domenii și fluxuri de date

Domenii cheie:

Identitate și conturi - înregistrare, autentificare, roluri, dispozitive, sesiuni.
Wallet & Ledger - conturi de numerar, portofele bonus, tranzacții, registru (numai adăugați).
Jocuri și pariuri - sesiuni de joc, pariuri, runde, calculul rezultatelor, integrare (RNG/Live/Crash etc.).
Bonusuri și promoții - freespins, cashback, vouchere, pariere (pariere), anti-abuz.
Plăți (casier) - pe rampă/off-rampă: hărți, APM, criptă/stablecoins, legare KYC.
KYC/AML/KYT & RG - Identitate/Adresa/Verificarea veniturilor, Screening-ul tranzacțiilor, Limite și Timeouts.
Risc și conformitate - limite de rate/plăți, liste de sancțiuni, geo-blocare, audit.
Catalog & Lobby - o listă de furnizori, jocuri, categorii, limite; Variante A/B.
Raportare & BI - P&L, GGR/NGR, retenție, ciclu de viață jucător, afiliați.
Observare & Ops - busteni, metrici, urme, alerte, semnale de fraudă.

Orchestrație: este construită o platformă modernă bazată pe evenimente: evenimente de schimb de servicii prin intermediul autobuzului (Kafka/NATS), operațiile critice sunt liniarizate (portofel/registru), subsistemele laterale sunt semnate și au răspuns asincron (bonusuri, BI, notificări).

2) Model stratificat

Strat de margine: gateway API, protecție WAF/bot, limite de rată, filtre geo/IP, steaguri de caracteristici.

Strat de service: microservicii autonome pe domenii; contracte sincrone - numai în cazul în care este nevoie de consistență instantanee (ex. portofel debit la pariu).

Eveniment autobuz: principalele evenimente de afaceri ('bet. plasat', 'rotund. stabilit „,” bonus. emis „,” kyc. verificat „,” plata. required').

Date: OLTP (Postgres/MySQL) pentru tranzacții; KV/Cache (Redis) pentru sesiuni/limite; stocarea obiectelor (S3) pentru jurnale și export; OLAP (ClickHouse/BigQuery) pentru analiză.

3) Portofel și registru: inima platformei

Principii:

Adăugați numai registrul: fiecare tranzacție financiară este o înregistrare cu tipul, suma, moneda, referința la sursă (rata, bonus, depozit).
Soldurile cash și bonus sunt postate. Nu puteți „amesteca” bani și bonusuri; utilizează o politică privind sursele de finanțare.
Atomicitatea debet→kredit: rate = debit de bani sau portofel bonus + crearea de hold; calcul rotund elimină dețin și face un credit/debit pe rezultatul.

Exemplu de tranzacții cu rate:

"LEDGER: HOLD' (−10. 00 EUR, sursa: cash, ref: betId)
SETTLE_DEBIT' (−10. 00 EUR) + 'LEDGER: PAYOUT' (+ 36. 00 EUR) - dacă WIN
'LEDGER: HOLD_RELEASE' (+ 10. 00 EUR) - dacă este GOL/PUSH

Cerințe:

Operațiuni idempotente (chei de idempotență prin 'requestId').
Blocare optimă pentru a proteja împotriva curselor.
Clar moneda de calcul și ratele de fixare pentru conversii.

4) Integrarea cu furnizorii de jocuri

Modele de portofel:

Fără sudură - echilibrul operatorului; pariu/decontare trece prin API-ul nostru în timp real.
Transfer - depozit la banca de joc de la furnizor; mai multă frecare, dar cerința de uptime a pungii mai mică.

Căi sincrone (critice):

"bet. locul "→ pre-auth în portofel (hold) →" acceptat/respins ".

Căi asincrone:

'round. soluționați "de la furnizor (webhook/WS) → stabiliți în registru → un eveniment la → de raportare/bonusuri de autobuz.

Standardizarea prin intermediul bridge: scheme de evenimente uniforme și identificatori 'roundId/betId', tabelul de cartografiere limită și pariurile laterale, normalizarea erorilor.

5) Bonusuri, pariuri și anti-abuz

Modele: bonusuri de depozit, freespins, retururi (cashback), misiuni, turnee.

Pariere: progresul pariurilor stocate separat; regula „ce pariuri contează” (procente pe categorii de jocuri).

Ordinea de a scrie-off: mai întâi fonduri bonus, apoi reale - sau invers, strict în conformitate cu politica.

Anti-modele ale jucătorului: pariuri pe rezultate opuse, pariuri minime pentru progresul fermei, transfer între jocuri cu greutăți diferite - prinse de reguli și marcarea.

6) KYC/AML/KYT и Joc Responsabil (RG)

KYC: ID/adresa/verificarea vârstei; limitele de control ale statutelor (depozit/în interiorul/betMax).

AML/KYT: screening de canale de plată și adrese on-lanț (pentru criptă), liste de sancțiuni, surse de fonduri.

RG: limite zilnice/săptămânale, termene, autoexcludere; blocarea controalelor sunt efectuate înainte de "bet. locul „и” plata. cerere ".

7) Numerar: depozite și plăți

Depozite: furnizori de carduri/AWS, cripto/grajduri, metode locale; confirmări de tip webhook; protecție împotriva riscurilor de chargeback.

Plăți: cozi, limite, principiul 4-ochi pentru sume mari; surse de fonduri → „numai soldul numerarului”.

Cripte la rampă/în afara rampei: conversie automată, adrese KYT, acoperire prin expunere.

8) Limite, riscuri și reguli regionale

Limitați profilurile ('DEFAULT', 'VIP _ A', 'VIP _ B', 'ULTRA') în funcție de țară/monedă/ACC.

Geo-blocarea prin IP/GPS/document.

Suprapuneri de joc/categorie, furnizorul interzice în jurisdicții.

Reacția la anomalii: explozii de pariuri, corelarea dispozitivelor/plăților, o mulțime de „VOID” de la un singur utilizator.

9) Observabilitate și funcționare

Valori: întârzieri portofel, eșec pariu, timp de calcul rotund, conversie depozita→stavka, GGR/NGR, plata SLA, cota de pariuri bonus.

Jurnale și urme: corelație "traceId' în toate evenimentele; depozitarea evenimentelor brute în depozitul „rece”.

Alerte: degradarea răspunsului portofelului, „VOID” spike, reconcilierea erorii raportului, creșterea „RG _ BLOCKED”.

Runbooks: proceduri de incidente clare (picătură furnizor, registru din sincronizare, runde anulate).

10) Securitate și confidențialitate

Auth: jetoane JWT/opace cu durată scurtă de viață, rotație la cheie ('kid'), mTLS la integrări critice.

Politici de acces: separarea strictă a rolurilor (operațiuni, finanțe, sprijin), 2FA; pentru plăți mari - bine de la a doua persoană.

Confidențialitatea datelor: criptare PII, tokenizarea datelor de plată, minimizarea stocării; GDPR/ștergere la cerere.

Audit: jurnale neschimbabile, semnătura evenimentelor critice, exportul pentru regulator.

11) Scalabilitate și toleranță la erori

Servicii Statles în spatele auto-scaler; cioburi orizontale pentru mese calde (tarife, jurnale de evenimente).

Registru - marjă verticală + replicare pentru citire/raportare; „înghețarea” schemelor de migrație prin mese de umbră.

Caching: Redis cu TTL și strategii de „două verificări” (citire + invalidare după evenimente).

DR/HA: multi-AZ, copii de rezervă cu recuperare regulată, RPO/RTO la nivelul cerințelor de reglementare.

Moduri de degradare: checkout autonom, dezactivarea bonusurilor „grele”, transferul jocurilor live la întreținere atunci când autobuzul nu este disponibil.

12) Contracte și exemple

Pariu (sincronizare, JSON/REST sau gRPC):

json
POST/pariuri/loc
{
„requestId':” 9a7f „...,” playerId': „p_123,” „portofel”: „cash”,
"roundId':" R-2025-10-17-19:20:05-PRAGM-Table12, "gameId':" pragm_live_roulette, "" selection ": [{" market ":" straight', "value": "17"}], "stake": {"cuantum": "10. 00 „, „monedă”:” EUR”}, „dispozitiv”: {„ip „:” 203. 0. 113. 5 ", "ua ": "Mozilla/"..}
}

Răspuns:

json
{
„stare”: „ACCEPTAT”, „betId':” bet_8cd..., „” balanceAfter „:” 245. 30, „hold':” 10. 00”, „limite”: {„maxBet”:” 5000. 00"}
}

Eveniment de autobuz (async):

json
{
"eveniment ":" rundă. settled "," roundId': "R-2025-10-17-19: 20: 05-PRAGM-Table12", "pariuri": [{"betId':" bet _ 8cd'..., "rezultat": "WIN", "miză": "10. 00 „, „plată”:” 360. 00 „}],” playerId': „p _ 123”, „ts':” 2025-10-17T19: 20:09. 231Z, „” traceId': „tr _ 5f1”..
}

13) Anti-modele (care rupe platforma)

Se amestecă bonus și numerar într-o singură tranzacție fără surse.

Jetoane cu durată lungă de viaţă şi stocarea lor pe client.

Lipsa idempotenței în operațiunile critice (se dublează debitul).

Monolit de raportare SQL pentru baza de date de luptă (OLAP vs. OLTP).

Împuternicire oarbă a furnizorului fără reconciliere şi limite.

Fără standard de fus orar (UTC peste tot!) în identificatori rotunzi și rapoarte.

Apelurile sincrone în domenii nefinanciare (bonusuri/notificări) blochează pariul.

14) Lista de verificare a lansării backend-ului cazinoului

Finanțe și portofel

Ledger append-only, idempotency, balance version.
Separarea numerar/bonus, politica sursă.
Ratele/conversiile sunt capturate în tranzacție.

Integrarea jocurilor

Contract de rată unică/decontare, format 'roundId/betId'.
Portofel fără sudură în mod implicit; Transfer - numai dacă este justificat.
Scripturi automate VOID/RAMBURSARE.

KYC/AML/RG

Politici înainte de admiterea la rată/plată; Statusuri ↔ limite KYC.
KYT pentru on-chain, screening de sancțiuni, depozitarea probelor.

Casierie

Webhooks/semnături, dublează/retraiele, se împacă cu furnizorii PSP/cripto.
4-ochi pe plăți mari, jurnalul de activitate al operatorului.

Observabilitate

Măsurători ale portofelului, latență rotundă, eșec al ofertei, SLA-uri de plată.
Urmele sunt end-to-end (traceId), alerte, runbooks.

Siguranță

mTLS/HMAC, JWT cu TTL scurt, rotație cheie.
Roluri/drepturi, 2FA, tokenizarea datelor de plată.

Date

OLTP/OLAP separare, CDC la DWH, S3 pentru evenimente brute.
Backup-uri și teste regulate de recuperare.

15) Linia de jos

Arhitectura cazinoului backend este un nucleu strict de bani și pariuri cu consistență liniară și periferice flexibile pe evenimente: bonusuri, analize, comunicații. Succesul este determinat nu de numărul de microservicii, ci de disciplină: limite de domeniu clare, un registru fără „magie”, idempotență, observabilitate și conformitate în mod implicit. Cu această fundație, platforma scalează între țări/valute/furnizori și rezistă la sarcini fără compromisuri privind securitatea și banii.