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 запрещён — только ручной/скриптовый с чек-листом.

Файлы/KYC-артефакты

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

WebSocket/Real-time

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

8) Платежи и провайдеры игр: много источников правды

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

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

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

9) Вебхуки и колбэки: устойчивый приём и воспроизведение

Inbox-паттерн: принимаем вебхук → проверяем подпись/HMAC → пишем в 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 — и даже крупная авария станет управляемым событием без потери доверия и денег.