Casino uchun failover, replikatsiya va DR-rejalar

1) Biznes maqsadlar: RTO/RPO va tanqidiy flou

RTO (xizmat qancha vaqt mavjud bo’lishi mumkin): login/stavka/depozit - soniya/daqiqa; hisobotlar - soatlar.

RPO (qancha ma’lumotlarni yo’qotish mumkin): hamyon/tranzaksiyalar - ~ 0-30 sek; telemetriya - daqiqa.

Tanqidiy flou: login, depozit/olib qo’yish, stavka/settlment, KYC/AML-kolbeklar, PSP/o’yin provayderlarining vebxuklari.

2) Ishdan chiqishga chidamlilik arxitektura patternlari

Active-Active (multi-region): ikkala hudud ham trafikni qayta ishlaydi; past RTO/RPO, murakkab konsistentlik.

Active-Standby: bir mintaqa ishlamoqda, ikkinchisi issiq; oddiy holat, bir daqiqalik RTO.

Cell-based: «kataklar» bo’yicha izolyatsiya (market/brand), mahalliy hodisalar hamma narsani yo’q qilmaydi.

Edge-pirog: Anycast CDN/WAF → mintaqaviy shlyuzlar → app-klasterlar → DB/replikatsiyali keshlar.

3) Trafik-menejment va tarmoq feyloveri

Anycast + CDN/WAF: L3/4/7 yutish, origin uchun health-chek.

DNS-faylover (past TTL, multi-value), Traffic Manager/GSLB salomatlik metrikasi bo’yicha.

Tezkor yo’lni o’zgartirish uchun anti-DDoS provayderi orqali BGP-e’lon.

Health chek (mantiqiy misol):

if p95_latency>threshold          5xx_rate>threshold          synthetic_login_fail:
drain(region_A); shift(traffic->region_B, ramp=5min)

4) Ma’lumotlar: hamyon, buyurtmalar, stavkalar

Haqiqat manbai - simlar jurnali (ledger): faqat append, idempotentlik’operation _ id’.

Kelishish: ledger, PSP va o’yin provayderlari o’rtasidagi davriy reconciliation-joblar.

Anti-dubl: idempotency-depozitlar/kolbeklar/to’lovlar uchun kalitlar; outbox/inbox.

5) DB replikatsiyasi: variantlar va murosalar

Jismoniy sinxron (semi-sync): minimal RPO, kechikish xavfi - nuqtali (hamyon) qo’llash.

Asinxron: yuqori unumdorlik/soddalik, RPO soniya-daqiqa - o’yin meta-ma’lumotlari, ma’lumotnomalar ostida.

Mantiqiy (CDC → boshqa mintaqaga oqim): moslashuvchan tanlash, xoch dvigatellari va tahlillar uchun qulay.

Keshlar (Redis/Memcached): haqiqat manbai sifatida emas; replika/snapshotlar, iliq startlar.

PITR: uzluksiz jurnallar (WAL/redo) ofsayt saqlash uchun, tiklash oynasi ≥ 7-30 kun.

6) Konsistentlik va kelishish shablonlari

Saga + Outbox: biznes tranzaksiyalari qadamlar zanjiri sifatida, voqealarni atomik ravishda e’lon qilish va DBga yozib qo’yish.

Exactly-once «ma’nosi bo’yicha»: operatsiyalarning idempotentligi, balans versiyalarini nazorat qilish (optimistic locking).

Eventual consistency kalitsiz flouda (liderbord, analitik); pul uchun strong.

7) Komponentlar va ularning feyloveri

API/backend

Statles-konteynyerlar, avtoskeyl, blue-green/canary; ombor orqali konfigi (versiyalash bilan).

Navbatlar/oqimlar

Kvorum-klasterlar (N = 3/5), kross-AZ replika; takrorlash va dlt-navbat siyosati.

Hamyon DB

Praymari v Region A, sinxro-replika v A (boshqa AZ), asinxron - v Region B; split-brain uchun avtomatik promote taqiqlangan - faqat chek varaqasi bilan qo’lda/skriptda.

Fayllar/KUS artefaktlari

Obyekt ombori, kross-mintaqaviy replika/CRR, KMS kalitlari.

WebSocket/Real-time

Kalitlar bo’yicha sharding (table/game/market), sticky-routing; feyloverda - rejoin-token bilan resubscribe.

8) To’lovlar va o’yin provayderlari: ko’plab haqiqat manbalari

PSP-faylover: har bir usul uchun kamida 2 provayder (karta, hamyon, kripto).

SLA/qiymat/BIN banlistlari bo’yicha foizli routing; tanazzulga uchragan PSPni avtomat bilan o’chirish.

O’yin provayderlari: zaxira kanallari/ASN allow-list, hududlarga alohida kalitlar, taym-autlarni izolyatsiya qilish.

9) Vebxuklar va kolbeklar: barqaror qabul qilish va takrorlash

Inbox-pattern: vebxukni qabul qilamiz → imzoni/NMASni tekshiramiz → immutable-inbox ga yozamiz → idempotent vorkeri bilan ishlaymiz.

Provayderlar retraisi: backoff +’event _ id ’/’ signature’bo’yicha dedup.

DRda: tartib nazorati bilan inbox replay (txn → settlement).

10) Bekaplar: 3-2-1 strategiyasi va tiklanishni tekshirish

3 ta nusxa/2 ta tashuvchi/1 ta ofsayt (va 1 ta - tanqidiy jurnallar uchun oflayn/WORM).

Jadvallar: kundalik snapshotlar + doimiy jurnallar; haftalik test-restore «qorong’u» stendga.

Tiklash kataloglari: «t- Δ vaqtida hamyonni qanday koʻtarish kerak».

11) DR-reja: rollar, ssenariylar, kommunikatsiyalar

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

Kanallar: war-room, status-sahifa, safport/sheriklar/affiliatlarga xabar namunalari.

Stsenariylar (minimal):

• AZ yo’qolishi, mintaqaning yo’qolishi, PSPning mavjud emasligi, DD klasterining pasayishi, o’yin provayderining tanazzulga uchrashi, kalitlarning chiqib ketishi, ommaviy 5xx.

12) DR-ssenariylar matritsasining namunasi

13) Runbook’i va avtomatlashtirish

«DR-cutover» tugmasi: validatsiyali qadamlar ketma-ketligi (freeze writes → promote → warm caches → ramp traffic).

Yaxlitlikni tekshirish skriptlari: ledger/hamyon summalarini solishtirish, balanslarning ziddiyatsizligi.

Feature-flags: avariya paytida tezkor disable reports/export/og’ir dashbordlar.

14) Feylover uchun kuzatish

SLO-metriklar trigger sifatida: login, depozit, stavka, o’yinni boshlash.

Технические: replication-lag, WAL-shipping, queue-lag, 5xx, p95, SYN backlog, WebSocket disconnects.

Boshqa mintaqalardan Synthetic stsenariylari: har daqiqada login/depozit/stavka.

end-to-end,’region’,’psp’,’game _ provider’belgilari.

15) Chaos/DR-mashqlar

GameDay har chorakda: AZ o’chirish, PSP degradatsiyasi, DB uzelini «yo’qotish», navbatni to’xtatish.

Retrospektiv: qarorlar qabul qilish vaqti, etishmayotgan alertlar, shovqin, tor joylar.

«His-tuyg’ular» emas, balki faktlar asosida RTO/RPO va avtomatlashtirishni tuzatish.

16) Xavfsizlik va komplayens

KMS/HSM (kross-mintaqaviy), rotatsiya va dual-control.

Audit va tranzaksiya jurnallari uchun WORM/immutability.

DPA/PSP/provayderlar bilan SLA/DR majburiyatlari va aloqa nuqtalari bo’yicha shartnomalar 24 × 7.

17) Feyloverning minimal siyosati misoli (psevdokod)

on Incident(type="REGION_DOWN"):
freeze_non_critical_writes()
promote_db(region=B)
verify_ledger_consistency()
warm_caches(region=B)
route_traffic(region=B, ramp=10%)
for step in [25%, 50%, 100%]:
if SLO_green(): ramp(step) else rollback()
announce_statuspage()

18) Tayyorlik chek-varaqasi (prod-ready)

• Har bir flou uchun RTO/RPO aniqlangan; biznes tomonidan qabul qilingan.
• Multi-AZ minimal; Hamyon, login va to’lovlar uchun multi-region.
• Ledger + idempotentlik (keys) + outbox/inbox; reja boʻyicha reconciliation.
• DB replikatsiyasi: lokal sync, DRda async; PITR yoqilgan, restore tekshirilgan.
• Usul, routing siyosati va test kalitlari uchun ikkita PSP; o’yin provayderlari - muqobil.
• DNS/GSLB/Anycast, sog’liq cheklari va sintetika, past TTL.
• Runbook’i va «DR-cutover» tugmasi, degradatsiya uchun feature-flags.
• SLO/alertlar/treysing; «DR-status» paneli.
• Har choraklik DR-mashqlar + retro; yangilangan aloqalar 24 × 7.

---

Xulosa

Ishonchli iGaming platformasi pul konturi atrofida quriladi: idempotentlik bilan o’tkazish jurnali, bashorat qilinadigan feylover, tekshiriladigan replikatsiya va muntazam DR-mashqlar. Tizimni kataklarga va hududlarga bo’ling, cutoverni avtomatlashtiring, ikkita PSP va zaxira o’yin provayderlarini saqlang, SLO va ledger yaxlitligini nazorat qiling va hatto katta avariya ham ishonchni yo’qotmasdan boshqariladigan hodisaga aylanadi.