Failover, реплікація та DR-плани для казино

1) Бізнес-цілі: RTO/RPO і критичні флоу

RTO (скільки часу сервіс може бути недоступний): логін/ставка/депозит - секунди/хвилини; звіти - годинник.

RPO (скільки даних можна втратити): гаманець/транзакції - ~ 0-30 сек; телеметрія - хвилини.

Критичні флоу: логін, депозит/вивід, ставка/сеттлмент, KYC/AML-колбеки, вебхуки PSP/ігрових провайдерів.

2) Архітектурні патерни відмовостійкості

Active-Active (multi-region): обидва регіони обробляють трафік; низький RTO/RPO, складна консистентність.

Active-Standby: один регіон в роботі, другий гарячий; простіше стан, RTO хвилини.

Cell-based: ізоляція по «осередках» (market/brand), локальні інциденти не валять все.

Edge-пиріг: Anycast CDN/WAF → регіональні шлюзи → app-кластери → БД/кеші з реплікацією.

3) Трафік-менеджмент і мережевий фейловер

Anycast + CDN/WAF: поглинання L3/4/7, health-чек на origin.

DNS-фейловер (низький TTL, multi-value), Traffic Manager/GSLB за метриками здоров'я.

BGP-анонс через провайдера анти-DDoS для швидкої зміни шляху.

Health-чек (приклад логіки):

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

4) Дані: гаманець, замовлення, ставки

Джерело істини - журнал проводок (ledger): тільки append, ідемпотентність по'operation _ id'.

Узгодження: періодичні reconciliation-джоби між ledger, PSP і провайдерами ігор.

Анти-дубль: idempotency-ключі для депозитів/колбеків/виплат; дедуплікація в outbox/inbox.

5) Реплікація БД: варіанти і компроміси

Фізична синхронна (semi-sync): мінімальний RPO, ризик затримок - застосовувати точково (гаманець).

Асинхронна: вище продуктивність/простота, RPO секунд-хвилини - під ігрові метадані, довідники.

Логічна (CDC → стрім в інший регіон): гнучка вибірковість, зручна для крос-движків і аналітики.

Кеші (Redis/Memcached): не як джерело істини; репліка/снапшоти, теплі старти.

PITR: безперервні журнали (WAL/redo) на офсайт-сховище, вікно відновлення ≥ 7-30 днів.

6) Консистентність і шаблони узгодження

Saga + Outbox: бізнес-транзакції як ланцюжок кроків, публікація подій атомарно із записом в БД.

Exactly-once «за змістом»: ідемпотентність операцій, контроль версій балансу (optimistic locking).

Eventual consistency в неключових флоу (лідерборд, аналітика); strong для грошей.

7) Компоненти та їх фейловер

API/бекенд

Статлес-контейнери, автоскейл, blue-green/canary; конфіги через сховище (з версіонуванням).

Черги/стріми

Кворум-кластери (N = 3/5), крос-AZ репліка; політики повторів і dlt-черги.

БД гаманця

Праймарі в Region A, синхро-репліка в A (інша AZ), асинхронна - в Region B; автоматичний promote при split-brain заборонений - тільки ручний/скриптовий з чек-листом.

Файли/КУС-артефакти

Об'єктне сховище з версіонуванням, крос-регіональна репліка/CRR, ключі в KMS.

WebSocket/Real-time

Шардінг по ключах (table/game/market), sticky-routing; при фейловері - resubscribe з rejoin-токеном.

8) Платежі та провайдери ігор: багато джерел правди

PSP-фейловер: мінімум 2 провайдера на кожен метод (карта, гаманці, крипто).

Процентний routing по SLA/вартості/банлістам BIN; вимкнення деградуючого PSP автоматом.

Ігрові провайдери: резервні канали/ASN allow-list, окремі ключі на регіони, ізоляція тайм-аутів.

9) Вебхукі і колбеки: стійкий прийом і відтворення

Inbox-патерн: приймаємо вебхук → перевіряємо підпис/НМАС → пишемо в immutable-inbox → обробляємо воркером ідемпотентно.

Ретраї провайдерів: backoff + дедуп по'event _ id '/' signature'.

При DR: реплей з inbox з контролем порядку (txn → settlement).

10) Бекапи: стратегія 3-2-1 і перевірки відновлення

3 копії/2 носія/1 офсайт (і 1 - офлайн/WORM для критичних журналів).

Розклади: щоденні снапшоти + постійні журнали; щотижневі test-restore на «темний» стенд.

Каталоги відновлення: «як підняти гаманець на момент t- Δ».

11) DR-план: ролі, сценарії, комунікації

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

Канали: war-room, статус-сторінка, шаблони повідомлень саппорту/партнерам/афіліатам.

Сценарії (мінімум):

• Втрата AZ, втрата регіону, недоступність PSP, падіння кластера БД, деградація провайдера ігор, витік ключів, масовий 5xx.

12) Приклад матриці DR-сценаріїв

13) Runbook'і і автоматизація

Кнопка «DR-cutover»: послідовність кроків з валідацією (freeze writes → promote → warm caches → ramp traffic).

Скрипти перевірки цілісності: звірка сум по ledger/гаманцю, несуперечливість балансів.

Feature-flags: швидкий disable репортів/експортів/важких дашбордів під час аварії.

14) Спостережуваність для фейловера

SLO-метрики як тригери: логін, депозит, ставка, запуск гри.

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

Synthetic сценарії з інших регіонів: логін/депозит/ставка кожну хвилину.

Трасування end-to-end, мітки'region','psp','game _ provider'.

15) Chaos/DR-навчання

GameDay щокварталу: відключення AZ, деградація PSP, «втрата» вузла БД, зупинка черги.

Ретроспектива: час прийняття рішень, відсутні алерти, шум, вузькі місця.

Коригування RTO/RPO і автоматизації на основі фактів, а не «відчуттів».

16) Безпека та комплаєнс

Ключі/секрети в KMS/HSM (крос-регіональні), ротація і dual-control.

WORM/immutability для журналів аудиту та транзакцій.

DPA/контракти з PSP/провайдерами на SLA/DR-зобов'язання і точки контакту 24 × 7.

17) Приклад мінімальної політики фейловера (псевдокод)

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) Чек-лист готовності (prod-ready)

• Визначені RTO/RPO на кожен флоу; прийняті бізнесом.
• Multi-AZ мінімум; Multi-region для гаманця, логіна і платежів.
• Ledger + ідемпотентність (keys) + outbox/inbox; reconciliation за розкладом.
• Реплікація БД: sync локально, async в DR; PITR включений, restore перевірений.
• Два PSP на метод, політика роутингу і тестові ключі; провайдери ігор - альтернативи.
• DNS/GSLB/Anycast, health-чеки і синтетика, низький TTL.
• Runbook'і і «кнопка DR-cutover», feature-flags для деградації.
• SLO/алерти/трейсинг; панель «DR-статус».
• Щоквартальні DR-навчання + ретро; оновлені контакти 24 × 7.

---

Резюме

Надійна iGaming-платформа будується навколо грошового контуру: журнал проводок з ідемпотентністю, передбачуваний фейловер, реплікація, що перевіряється, і регулярні DR-навчання. Розділіть систему на осередки і регіони, автоматизуйте cutover, тримайте два PSP і запасних провайдерів ігор, стежте за SLO і цілісністю ledger - і навіть велика аварія стане керованою подією без втрати довіри і грошей.