Як влаштований failover і резервне копіювання в iGaming

Навіщо iGaming особлива дисципліна DR/BCP

Казино-платформа - це гроші в реальному часі (гаманець/леджер), живі раунди (RNG/Live), виплати, афіліати і строгий комплаєнс. Будь-яка «діра» в доступності швидко перетворюється на фінансові та юридичні ризики. Тому архітектура будується навколо передбачуваного відновлення: відомі цілі, відомі сценарії, відрепетирувані процедури.

Базові цілі та терміни

RTO (Recovery Time Objective): час відновлення сервісу.

Для гаманця/леджера: ≤ 60-300 сек (внутрішньорегіональний фейловер), ≤ 15 хв (міжрегіональний DR).

RPO (Recovery Point Objective): допустима втрата даних.

Для леджера: 0-5 сек (синхронна/квазісинхронна реплікація), для звітності: ≤ 15 хв.

SLA и Error Budget: формалізують компроміси між швидкістю змін і стабільністю.

Шари відмовостійкості

1) Інфраструктура: Multi-AZ / Multi-Region

Multi-AZ (мінімум 3 зони): всі критичні сервіси розподілені по зонах, автоматичний фейловер БД/шини.

Multi-Region DR: «гарячий» (Active-Active) або «теплий» (Active-Passive) другий регіон з ізоляцією по юрисдикціях (data residency).

Рішення, коли який режим:

Active-Active: низька латентність до гравців у двох регіонах, cross-region леджер через синхронізацію подій + суворе одиничне «місце істини» для розрахунків.
Active-Passive (warm): простіше і дешевше; пасив тримає теплі інстанси + репліки БД, але трафік не обслуговує.

2) Мережа і периметр

Дубльовані ingress/WAF, Anycast або DNS-фейловер з перевірками здоров'я.

Окремі egress-шлюзи для каси і провайдерів, списки дозволених IP в обох регіонах.

3) Дані та черги

Реляційні БД (Postgres): Patroni/Managed HA, синхронні репліки в AZ, асинхронна репліка в DR-регіон (з моніторингом лагів). PITR зі снапшотами кожні N хвилин + архів WAL.

OLAP (ClickHouse/BigQuery): реплікація/шардування; втрата допустима вище (RPO до 15-30 хв).

Кеш (Redis): кластер з failover, але не джерело істини; при перемиканні - теплий прогрів.

Шина подій (Kafka/NATS): дзеркальні кластери та/або cross-cluster-mirroring, гарантія «at-least-once», контроль ідемпотентності на споживачах.

4) Додатки та домени

Гаманець/леджер: stateful-ядро з суворою консистентністю, один «майстер-райтер» на регіон; при міжрегіональному DR - процедура «elected writer» з блокуванням подвійного запису.

Ігровий bridge/API: stateless, горизонтальний фейловер по health-чеках; idempotencyKey для всіх фінансових шляхів.

Бонуси/повідомлення/ETL: допускають відкладену обробку, перезапускаються з черг.

Каса (PSP/крипта): мультипровайдерна стратегія (мінімум 2 рейки на країну), швидке перемикання мерчантів/ендпоінтів.

5) Live-стріми

WebRTC/LL-HLS гейтвеї з регіональними edge-вузлами; fallback-маршрути на LL-HLS при деградації WebRTC.

Утримання логіки ставок поза плеєром, щоб перезапуск стріму не впливав на розрахунок.

Failover-патерни

Актив-актив (дворегійний)

Плюси: мінімальні RTO/RPO, близькість до гравців.

Мінуси: складність леджера і конфліктів запису, дорога сітка.

Практика: «один письменник на домен» + event sourcing для відтворення станів у сусідньому регіоні.

Актив-пасив (теплий)

Плюси: баланс ціни/складності.

Мінуси: RTO вище, потрібен відпрацьований план «промоушена» пасивного регіону.

Практика: автоматика + ручне підтвердження (4-очний принцип) при перемиканні гаманця.

Внутрішньорегійний (Multi-AZ)

Автофейловер БД/кешів/ingress.

Без зміни DNS/Anycast, RTO секунди-хвилини.

Резервне копіювання (Backup) за класами даних

Клас	Приклади	Метод	Частота	Зберігання	Верифікація
Транзакції грошей/леджер	Postgres (гаманець, леджер)	Снапшоти + WAL архів (PITR), логічна репліка	5-15 хв WAL, снапшот 1-4 год	Об'єктне сховище з Object Lock (WORM), крос-регіон	Щотижневі DR-відновлення «на холодну» + порівняння контрольних сум
Події	Kafka топіки	Tiered storage + mirror в DR	Безперервно	Об'єктне сховище	Реплей тестових вікон
OLAP/звітність	ClickHouse/BigQuery	Снапшоти/експорт партій	1-6 год	Об'єктне сховище	Читання контрольних вибірок
Статичні артефакти	квитки, логи, експорт	Версіонований S3, Glacier	Щодня	WORM/версії	Періодичний restore
Секрети/ключі	KMS/HSM метадані	Експорт з обгорткою, dual-control	За графіком	HSM-репліки	Тест розшифровки

Принципи:

Бекап шифрується в спокої і транзиті, ключі - в KMS/HSM.
Immutable-режим (WORM) для критичних бекапів (захист від стирання/шифрувальників).
Каталог бекапів з метаданими (версія схеми, вікно WAL, контрольні суми).
PITR обов'язкова для леджера.

Дані та ідемпотентність: як уникати «дірок» при фейловері

IdempotencyKey на запитах'bet. place`, `payout. request`, `cashier. webhook`.

Леджер - тільки append-only: повторний settle створить коригувальний запис, а не «перезапис».

Транзакційні замки/версіонування балансу захищають від гонок при перемиканні ролі письменника.

Дедуплікація подій (consumer-side, хеш по ключових полях).

Каса, PSP і крипта: план B завжди включений

Мінімум два провайдера на метод оплати (карта/АРМ), заздалегідь заведені мерчант-акаунти в обох регіонах.

Для стейблкоінів - дві мережі (наприклад, TRC-20 і ERC-20) і два on/off-ramp-провайдера.

Маршрутизатор виплат: при збої PSP миттєво перемикає на резервний, веде журнал причин.

KYT/AML-потоки дублюються; якщо зовнішній сервіс недоступний - «degraded mode» з ручною ескалацією.

Операційні процедури (Runbooks)

Автоматичні

Health-чек ланцюжка ingress → API → гаманець → БД → провайдер.

Автовідключення «важких» функцій (турніри/місії) при деградації гаманця.

Таймаути/ретраї з експоненціальною паузою і строгими дедлайнами.

Ручні (з підтвердженням)

Промоушен DR-регіону в актив: чеклісти по кроках, журналювання, комм-шаблони (саппорт/партнери/регулятор).

Компенсації/VOID за раундами: коди причин, посилання на відеофід, підпис відповідальних.

Розморожування виплат з подвійним контролем.

Навчання та перевірки готовності

Game Day/Chaos Drill щомісяця: відключення AZ, деградація БД, падіння провайдера.

Full DR Rehearsal щоквартально: підняти регіон DR «в повний зріст», прогнати реальні сценарії ставок/виплат.

Restore-тести: відновити леджер на момент часу T, звірити з контрольним P&L і хеш-зрізами.

Table-top з комплаєнсом: хто і кого повідомляє, які звіти формуються (регулятор, PSP, афіліати).

Спостережуваність і сигнали фейловера

SLO-метрики: p95 latency гаманця, частка'bet. rejected', час settle раунду, SLA виплат, лаг реплікації БД, лаг Kafka-консьюмерів.

Події перемикань: алерты «role change», «replication lag > X», «object-lock violation».

Дашборди DR: поточна роль вузлів, RPO-оцінка (хвилини WAL), статус PITR-вікна.

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

Ізоляція даних по юрисдикціях (EU/UK/CA/...): реплікація в межах дозволеного законами.

Журнали незмінні (S3 Object Lock/WORM), ретеншн по регуляторних термінах.

Секрети: ротація ключів, поділ обов'язків (dual-control) для операцій DR.

Аудит-трейл всіх перемикань і відновлень.

Анти-патерни, які ламають DR

Один PSP/одна мережа стейблкоіна на країну - немає резервної рейки.

OLTP і OLAP на одній БД - відновлення блокує «живі» операції.

Немає idempotencyKey - дублі дебету/виплат при ретраях.

Бекапи без регулярного restore-тесту - «шредінгерівський бекап».

Відсутність WORM/immutability - вразливість до інсайдерського/шкідливого видалення.

DNS-фейловер без коротких TTL і прогрітих ендпоінтів.

Єдиний письменник леджера в двох регіонах одночасно - розщеплення стану.

Чек-лист готовності до аварій

Архітектура

Multi-AZ для всіх критичних сервісів, документована топологія.
DR-регіон з описаною роллю (Active-Active/Passive) і бюджетом.

Дані

Postgres: PITR, снапшоти, лаг-моніторинг, регулярні відновлювальні тести.
Kafka/NATS: дзеркалювання/архів, реплей-план.
ClickHouse/OLAP: партійні бекапи, відновлення вибірок.
S3: Object Lock (WORM), версії, крос-регіон.

Програми

Idempotency в грошах, append-only леджер, версіонування балансу.
Авто-feature-degrade при інцидентах (турніри/місії off).
Канарські перевірки перед перемиканням регіону.

Каса і крипта

По два провайдера на метод і по дві мережі для стейблів.
Маршрутизація і журнал причин перемикань.
KYT/AML в degrade-режимі з ескалацією.

Операції

Runbooks з RACI і телефонами чергових.
Щомісячні Chaos-дні і квартальні Full-DR навчання.
Комунікаційні шаблони (саппорт, партнери, регулятор).

Спостережуваність

Дашборди RTO/RPO, алерти ролі БД, лагів, відмов ставок/виплат.
Аудит-лог перемикань і відновлень.

Надійність iGaming - це не «кнопка фейловера», а система звичок: географічна ізоляція, передбачувані RTO/RPO, ідемпотентні гроші, багаторельсова каса, immutable-бекапи, регулярні навчання і прозора комунікація. Така дисципліна дозволяє переживати збої без втрат в леджері, без «залиплих» раундів і без ударів по довірі гравців і регуляторів.