Как устроен 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 всегда включён

Минимум два провайдера на метод оплаты (карта/APM), заранее заведённые мерчант-аккаунты в обоих регионах.

Для стейблкоинов — две сети (например, 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-бэкапы, регулярные учения и прозрачная коммуникация. Такая дисциплина позволяет переживать сбои без потерь в леджере, без «залипших» раундов и без ударов по доверию игроков и регуляторов.