Cum failover și de backup de lucru în iGaming

De ce are nevoie iGaming de o disciplină DR/BCP specială

O platformă de cazino este bani în timp real (portofel/registru), runde live (RNG/Live), plăți, afiliați și conformitate strictă. Orice gaură de accesibilitate se transformă rapid în riscuri financiare și juridice. Prin urmare, arhitectura este construită în jurul recuperării previzibile: obiective cunoscute, scenarii cunoscute, proceduri repetate.

Obiective și termeni de bază

RTO - Obiectivul timpului de recuperare

Pentru portofel/registru: ≤ 60-300 sec (feilover intraregional), ≤ 15 min (DR interregional).

Recovery Point Obiectiv (RPO) - pierdere de date acceptabilă.

Pentru registru: 0-5 secunde (replicare sincronă/cvasi-sincronă), pentru raportare: ≤ 15 minute.

SLA și bugetul de eroare: Formalizați compromisuri între rata de schimbare și stabilitate.

Straturi de toleranță la erori

1) Infrastructură: Multi-AZ/Multi-Regiune

Multi-AZ (minim 3 zone): toate serviciile critice sunt distribuite pe zone, baze de date automate/failover de autobuz.

Multi-regiune DR: "fierbinte" (Active-Active) sau "cald' (Active-Pasive) a doua regiune, cu izolare de jurisdicție (rezidență de date).

Decide când ce mod:

Active-Active: latență scăzută pentru jucătorii din două regiuni, registru transregional prin sincronizarea evenimentelor + un singur „loc al adevărului” strict pentru calcule.
Activ-pasiv (cald): mai simplu și mai ieftin; pasivul deține instanțe calde + replici de baze de date, dar nu servește traficului.

2) Rețea și perimetru

Duplicat intrare/WAF, Anycast sau DNS feilover cu controale de sănătate.

Gateway-uri de ieșire separate pentru case de marcat și furnizori, liste de IP permise în ambele regiuni.

3) Date și cozi

Baze de date relaționale (Postgres): Patroni/Managed HA, replici sincrone în AZ, replici asincrone în regiunea DR (cu monitorizare lag). PITR cu instantanee la fiecare N minute + arhiva WAL.

OLAP (ClickHouse/BigQuery): replicare/sharding; pierderea este acceptabilă mai sus (RPO până la 15-30 min).

Cache (Redis): un grup cu failover, dar nu o sursă de adevăr; în timpul comutării - încălzire.

Event bus (Kafka/NATS): clustere oglindă și/sau cross-cluster-oglindire, cel puțin o dată de garanție, controlul idempotency pe consumatori.

4) Aplicații și domenii

Portofel/registru: nucleu statuar cu consistență strictă, un „scriitor maestru” pe regiune; cu DR interregional - procedura „scriitor ales” cu o blocare dublă intrare.

Joc bridge/API: apatrid, orizontal feiler pentru controale de sănătate; idempotencyKey pentru toate căile financiare.

Bonusuri/notificări/ETL: permiteți procesarea întârziată, reporniți de la cozi.

Box office (PSP/criptă): strategie multi-provider (cel puțin 2 șine pe țară), comutare rapidă a comercianților/punctelor finale.

5) Fluxuri live

Gateway-uri WebRTC/LL-HLS cu noduri regionale de margine; rute de rezervă pe LL-HLS sub degradarea WebRTC.

Menținerea logicii de pariere în afara jucătorului, astfel încât repornirea fluxului să nu afecteze calculul.

Failover-modele

Activ-activ (biregional)

Pro: RTO/RPO minimal, apropierea de jucători.

Contra: complexitatea registrului și înregistrarea conflictelor, grila scumpă.

Practică: „un scriitor pe domeniu” + sursa de evenimente pentru a reproduce statele dintr-o regiune vecină.

Răspunderea pentru active (cald)

Pro: Echilibru preț/dificultate.

Contra: RTO de mai sus, au nevoie de un plan dovedit pentru a „promova” o regiune pasivă.

Practică: automatizare + confirmare manuală (principiul 4-ochi) la comutarea portofelului.

Intraregional (Multi-AZ)

Baza de date/cache/autofailer de intrare.

Nici o schimbare DNS/Anycast, RTO secunde-minute.

Backup după clasa de date

Clasă	Exemple	Metodă	Frecvenţă	Depozitare	Verificare
Tranzacții bănești/Registru	Postgres (portofel, registru)	Instantanee + arhivă WAL (PITR), replică logică	5-15 min WAL, instantaneu 1-4 h	Stocarea obiectelor cu Object Lock (WORM), Cross Region	Comparație săptămânală a sumei de control DR Cold +
Evenimente	Kafka topiks	Depozitare pe niveluri + oglindă в DR	Continuu	Stocarea obiectelor	Ferestre de încercare reluare
OLAP/Raportare	ClickHouse/BigQuery	Instantanee/export de loturi	1-6 ore	Stocarea obiectelor	Citirea probelor de testare
Artefacte statice	bilete, busteni, export	Versioned S3, Ghețar	Zilnic	WORM/versiuni	Restaurare periodică
Secretele/Cheile	Metadate KMS/HSM	Export cu ambalaj, dual-control	În grafic	Remarci HSM	Test de decriptare

Principii:

Copia de rezervă este criptată în repaus și în tranzit, cheile sunt criptate în KMS/HSM.
Mod imuabil (WORM) pentru backup-uri critice (protecție împotriva ștergerii/ransomware).
Catalog de backup-uri cu metadate (versiune schema, fereastra WAL, sume de control).
PITR este obligatoriu pentru registru.

Date și idempotență: cum să evitați „găurile” cu un feiler

IdempotencyKey pe „pariu” cereri. locul ',' plata. cerere „,” casier. webhook '.

Ledger - numai adăugați-numai: soluționarea repetată va crea o intrare de corecție, nu o „rescriere”.

Încuietorile tranzacționale/versiunile de echilibru protejează împotriva curselor la comutarea rolurilor de scriitor.

Deduplicarea evenimentelor (partea consumatorului, hash după câmpurile cheie).

Casă de marcat, PSP și criptă: planul B este întotdeauna inclus

Cel puțin doi furnizori pentru metoda de plată (card/AWP), conturi comerciale prestabilite în ambele regiuni.

Pentru stablecoins - două rețele (de exemplu, TRC-20 și ERC-20) și doi furnizori de on/off-rampă.

Router de plată: în caz de eșec, PSP trece instantaneu la backup, păstrează un jurnal al motivelor.

Fluxurile KYT/AML sunt duplicate; dacă serviciul extern nu este disponibil - „mod degradat” cu escaladare manuală.

Proceduri operaționale (Runbooks)

Automată

Verificarea lanțului de intrare API portofel furnizor de baze de date.

Dezactivarea automată a funcțiilor „grele” (turnee/misiuni) atunci când portofelul este degradat.

Timeouts/retrageri cu pauză exponențială și termene limită stricte.

Manual (cu confirmare)

Promovarea regiunii DR într-un activ: liste de verificare prin pași, logare, com-șabloane (suport/parteneri/regulator).

Compensare/VOID prin runde: provoca coduri, link-uri către ghidul video, semnătura celor responsabili.

Dezghețarea plăților cu dublu control.

Exerciții și verificări de pregătire

Game Day/Chaos Drill lunar: oprirea AZ, degradarea bazei de date, picătură furnizor.

Complet DR Repetiție trimestrial: ridica regiunea DR „în creștere completă”, rula scenarii reale de pariuri/plăți.

Restaurați testele: restaurați registrul în timp T, verificați cu feliile de control P&L și hash.

Tabelul de sus cu conformitatea: cine și cine notifică ce rapoarte sunt generate (regulator, PSP, afiliați).

Semnale de observabilitate și feilover

Măsurători SLO: latență pungă p95, share 'bet. respins ", timpul de decontare rotund, plata SLA, decalajul replicării bazei de date, întârzierea consumatorului Kafka.

Comutarea evenimentelor: alerte „schimbare de rol”, „decalaj replicare> X”, „încălcare obiect-blocare”.

Tablouri de bord DR: rol curent nod, scor RPO (minute WAL), starea ferestrei PITR.

Siguranță și conformitate

Izolarea datelor în funcție de jurisdicție (EU/UK/CA/...): replicarea în limitele legale.

Jurnale fixe (S3 Object Lock/WORM), retenție prin termene de reglementare.

Secrete: rotație cheie, dual-control pentru DR

Pista de audit a tuturor comutatoarelor și restaurări.

Anti-modele care sparg DR

O rețea PSP/o rețea stablecoin pe țară - nici o șină de rezervă.

OLTP și OLAP pe aceeași bază de date - blocuri de recuperare operațiuni live.

Fără idempotencyKey - debit/plată dublează pentru retroys.

Backup-urile fără un test regulat de restaurare sunt „Schrödinger backup”.

Lipsa WORM/imutabilitate - vulnerabilitate la ștergerea din interior/rău intenționată.

Feilover DNS fără TTL-uri scurte și criterii finale încălzite.

Un singur scriitor de registru în două regiuni în același timp este divizarea de stat.

Lista de verificare a pregătirii pentru situații de urgență

Arhitectură

Multi-AZ pentru toate serviciile critice, topologie documentată.
DR-regiune cu rol descris (Active-Active/Pasive) și buget.

Date

Postgres: PITR, instantanee, monitorizare lag, teste regulate de recuperare.
Kafka/NATS: oglindire/arhivă, plan de reluare.
ClickHouse/OLAP: backup lot, restaurarea probelor.
S3: Object Lock (WORM), versiuni, transversală.

Aplicații

Idempotence în bani, adăuga-numai registru, echilibru versioning.
Auto-feature-degrade pe incidente (turnee/misiuni off).
Verificări canare înainte de schimbarea regiunii.

Casa de bilete și cripta

Doi furnizori pe metodă și două rețele pentru grajduri.
Rutare și comutare jurnal cauza.
KYT/AML în modul degrade cu escaladare.

Operațiuni

Runbooks cu RACI și telefoane însoțitoare.
Zile lunare de haos și exerciții trimestriale Full-DR.
Șabloane de comunicare (suport, parteneri, regulator).

Observabilitate

Panouri de bord RTO/RPO, alerte de rol DB, lag-uri, eșecuri de ofertă/plată.
Jurnal de audit de switch-uri și restaurări.

Fiabilitatea iGaming nu este un „buton feiler”, ci un sistem de obiceiuri: izolare geografică, RTO/RPO previzibil, bani idempotenți, casierie multi-feroviară, backup-uri imuabile, exerciții regulate și comunicare transparentă. Această disciplină vă permite să experimentați eșecuri fără pierderi în registru, fără runde „blocate” și fără a lovi încrederea jucătorilor și a autorităților de reglementare.