Awaria, replikacja i plany DR kasyn

1) Cele biznesowe: RTO/RPO i przepływ krytyczny

RTO (jak długo usługa może być niedostępna): login/rate/deposit - sekundy/minuty; raporty - godziny.

RPO (ile danych można stracić): portfel/transakcje - ~ 0-30 sekund; telemetria - minuty.

Przepływ krytyczny: login, deposit/withdrawal, bet/settlement, KYC/AML-collars, PSP/game provider webhooks.

2) Wzorce tolerancji błędów architektonicznych

Active-Active (multi-region): oba regiony zajmują się ruchem; niski poziom RTO/RPO, złożona konsystencja.

Active-Standby: jeden region w eksploatacji, drugi gorący; łatwiejszy stan, minuty RTO.

Na bazie komórki: izolacja przez „komórki” (rynek/marka), lokalne incydenty nie obniżają wszystkiego.

Ciasto krawędzi: Anycast CDN/WAF → regionalne bramy → klastry aplikacji → DB/bufory z replikacją.

3) Zarządzanie ruchem i fałszywe sieci

Anycast + CDN/WAF: wychwyt L3/4/7, kontrola zdrowotna pochodzenia.

DNS-feilover (low TTL, multi-value), Traffic Manager/GSLB na mierniki zdrowia.

Ogłoszenie BGP za pośrednictwem dostawcy anty-DDoS do szybkiej zmiany ścieżki.

Ocena stanu zdrowia (przykład logiki):

jeśli p95_latency>threshold        5xx_rate>threshold        synthetic_login_fail:
drenaż (region_A); zmiana (handel -> region _ B, rampa = 5min)

4) Dane: portfel, zamówienia, zakłady

Źródłem prawdy jest księga: tylko dodaj, idempotencja przez 'operation _ id'.

Pojednanie: okresowe prace pojednawcze pomiędzy księgą, PSP i dostawcami gier.

Anty-double: klucze idempotencji do depozytów/kiełbasek/płatności; deduplikowanie do skrzynki odbiorczej/skrzynki odbiorczej.

5) Replikacja bazy danych - opcje i tradeoffs

Synchroniczny fizyczny (półsynchronizacja): minimalny RPO, ryzyko opóźnień - stosować pointwise (portfel).

Asynchroniczny: wyższa wydajność/prostota, RPO sekund-minut - dla metadanych gry, książek referencyjnych.

Logiczne (CDC → strumień do innego regionu): elastyczna selektywność, wygodna dla silników krzyżowych i analityki.

Caches (Redis/Memcached): nie jako źródło prawdy; repliki/migawki, ciepłe zaczynają.

PITR: dzienniki ciągłe (WAL/redo) do magazynu offsetowego, okno odzysku ≥ 7-30 dni.

6) Wzorce spójności i pojednania

Saga + Outbox: transakcje biznesowe jako łańcuch kroków, publikujące wydarzenia atomowo z pisaniem do bazy danych.

Dokładnie raz „w znaczeniu”: idempotencja operacji, kontrola wersji bilansu (blokowanie optymistyczne).

Ewentualna spójność przepływów innych niż kluczowe (tablica liderów, analityka); silny dla pieniędzy.

7) Elementy i ich feilover

API/backend

Pojemniki na statki, autoskale, niebiesko-zielone/kanarkowe; konfiguracje przez przechowywanie (z wersją).

Kolejki/strumienie

Kworum klastry (N = 3/5), replika cross-AZ; redo polityki i dlt kolejek.

Portfel DB

Primari w regionie A, replika synchroniczna w A (inne AZ), asynchroniczna w regionie B; automatyczna promocja z podziałem mózgu jest zabroniona - tylko ręczna/skryptowana listą kontrolną.

Pliki/CUS Artefakty

Przechowywanie obiektów z wersją, replika cross-regionalna/CRR, klawisze w KMS.

WebSocket/w czasie rzeczywistym

Shading przez klucze (table/game/market), sticky-routing; z feiler - resubscribe z tokenem rejoin.

8) Płatności i dostawcy gier: Wiele źródeł prawdy

PSP-feilover: co najmniej 2 dostawców dla każdej metody (karta, portfele, krypta).

Routing procentowy według SLA/wartość/Banlists BIN; wyłączenie zdegradowanego PSP przez wyłącznik automatyczny.

Dostawcy gier: kanały kopii zapasowych/ASN allow-list, poszczególne klucze do regionów, izolacja czasu.

9) Haki i kiełbaski: zrównoważony odbiór i reprodukcja

Skrzynka odbiorcza-wzór: akceptujemy hak → sprawdź podpis/NMAS → napisz w niezmiennej skrzynce odbiorczej → przetwarzaj pracownika idempotently.

Przekłady dostawców: backoff + dedup przez 'event _ id'/' signature'.

W DR: powtórka z skrzynki odbiorczej z kontrolą zamówienia (txn → rozliczenie).

10) Kopie zapasowe: 3-2-1 strategia i kontrole odzyskiwania

3 kopie/2 media/1 offsite (i 1 offline/WORM dla czasopism krytycznych).

Harmonogram: codzienne migawki + czasopisma stałe; cotygodniowe przywracanie testów do „ciemnego” stoiska.

Katalogi odzyskiwania: „Jak podnieść portfel w czasie t-”.

11) Plan DR: role, scenariusze, komunikacja

Рола: Incident Commander, Comms, DB Lead, App Lead, Payments/Game PM, SRE Oncall.

Kanały: pokój wojenny, strona stanu, szablony wiadomości dla wsparcia/partnerów/partnerów.

Scenariusze (minimum):

• Utrata AZ, utrata regionu, niedostępność PSP, spadek klastra bazy danych, degradacja dostawcy gier, wyciek klucza, masywne 5xx.

12) Przykład macierzy scenariusza DR

13) Książka startowa i automatyka

„DR-cutover” przycisk: kolejność kroków z walidacją (zamrażanie pisze → promować → ciepłe bufory → ruch na ziemi).

Skrypty kontroli integralności: uzgodnienie kwot księgowych/portfelowych, spójność bilansu.

Flagi funkcji: szybko wyłączyć raporty/eksport/ciężkie deski rozdzielcze podczas wypadku.

14) Możliwość obserwacji feilover

Metryki SLO jako wyzwalacze: login, deposit, bet, start gry.

Тебнивеский: replikacja-lag, WAL-shipping, queue-lag, 5xx, p95, SYN backlog, WebSocket odłącza.

Scenariusze syntetyczne z innych regionów: login/deposit/bet co minutę.

Ślady końcowe, „region”, „psp”, znaczniki „game _ provider”.

15) Ćwiczenia chaosu/DR

Kwartał GameDay: odłączenie AZ, degradacja PSP, „utrata” węzła bazy danych, zatrzymanie kolejki.

Retrospektywne: czas podejmowania decyzji, brakujące wpisy, hałas, wąskie gardła.

Dostosowanie RTO/RPO i automatyzacja w oparciu o fakty, a nie „doznania”.

16) Bezpieczeństwo i zgodność

Klucze/sekrety w KMS/HSM (cross-regional), rotacja i podwójna kontrola.

WORM/immunitet dla dzienników kontroli i transakcji.

Umowy DPA/PSP/dostawcy na zobowiązania SLA/DR i 24 × 7 punktów kontaktowych.

17) Przykład minimalnej polityki Feilover (pseudokoda)

w sprawie incydentu (typ = „REGION _ DOWN”):
freeze_non_critical_writes ()
promote_db (region = B)
verify_ledger_consistency ()
warm_caches (region = B)
route_traffic (region = B, rampa = 10%)
dla etapu [25%, 50%, 100%]:
jeśli SLO_green (): rampa (krok) inna rolka ()
announce_statuspage ()

18) Lista kontrolna Prod-ready

• Zdefiniowany RTO/RPO na przepływ; akceptowane przez firmę.
• Minimum multi-AZ; Multi-region dla portfela, login i płatności.
• Księga + idempotencja (klawisze) + skrzynka odbiorcza/skrzynka odbiorcza; pojednanie w harmonogramie.
• Replikacja bazy danych: synchronizacja lokalna, async w DR; PITR włączone, przywrócić sprawdzone.
• Dwa PSP na metodę, zasady routingu i klucze testowe; dostawcy gier są alternatywami.
• DNS/GSLB/Anycast, kontrole zdrowotne i syntetyka, niski poziom TTL.
• Runbook i przycisk DR-cutover, flagi funkcji do degradacji.
• SLO/alerty/odwzorowanie; Panel stanu DR.
• Ćwiczenia kwartalne DR + retro; zaktualizowane kontakty 24 × 7.

---

Wznów streszczenie

Niezawodna platforma iGaming jest zbudowana wokół obwodu monetarnego: dziennik postów z idempotencją, przewidywalny feiler, weryfikowalne replikacje i regularne ćwiczenia DR. Podziel system na komórki i regiony, zautomatyzuj cięcie, utrzymuj dwa dostawców usług płatniczych i dostawców gier zapasowych, monitoruj integralność SLO i księgi - a nawet poważny wypadek stanie się wydarzeniem możliwym do opanowania bez utraty zaufania i pieniędzy.