Как RGS обеспечивает стабильность и телеметрию слотов
Полный текст статьи
1) Роль RGS в стабильности и прозрачности
RGS (Remote Game Server) — ядро RNG-контента студии. Он генерирует исходы раундов, ведёт состояния бонусов, интегрируется с платёжным контуром платформы/агрегатора и поставляет телеметрию для BI и регуляторов. От его стабильности зависит: отсутствие дублей сеттлментов, низкая латентность раунда, корректность джекпотов/миссий и достоверность отчётности.
2) Целевые SLO и инварианты над деньгами
Бизнес-SLO (минимум):- p95 `bet/settle` < 200 мс (без платёжных хопов), ошибка `< 0.1%`.
- «Потерянных/дублированных сеттлментов» = 0.
- Доставка событий в шину/BI ≤ 5 мин.
- Доступность критичного API (bet/settle/rollback) ≥ 99.95%.
- Истина по балансу — у кошелька платформы, RGS хранит только состояние раундов.
- Все денежные вызовы идемпотентны: `Idempotency-Key`, уникальные `bet_id`/`round_id`.
- Компенсации — сагами, а не «ручными правками» БД.
3) «Антихрупкая» архитектура стабильности
3.1 Идемпотентность и саги
Команды `bet.authorize`, `bet.settle`, `rollback` с ключём идемпотентности и дедупликацией.
Сага «ставка → исход → кредит» с чёткими статусами (`started`, `settled_pending_credit`, `credited`, `compensated`).
3.2 Outbox/CDC и гарантированная доставка
Событие записывается в outbox в рамках одной транзакции с изменением состояния раунда.
Фоновый паблишер → шина (Kafka/Pulsar); для DWH — CDC (Debezium/аналоги).
3.3 Back-pressure и очереди
Буферизация `settle`/`jackpot.trigger` в очередях; защита от «штормов ставок».
Токен-бакеты/лимиты на `session_id` и провайдера; graceful-деградация «no new sessions».
3.4 Канареечные релизы и фича-флаги
1–5% трафика на новую версию, авто-роллбек по SLO.
Включение спорных механик (Bonus Buy, новые пулы RTP) — через фичфлаг с instant off.
3.5 Стейт и масштаб
Игровой стейт минимален; sticky-сессии по `session_id` или внешний стор (Redis/SQL) с TTL+jitter.
Горизонтальное масштабирование воркеров `settle`/`jackpot` независимо от API-фронтов.
3.6 Здоровье интеграций
Health-пробы провайдера/агрегатора: `ping`, `config`, `wallet` latency.
Автоматическое понижение нагрузки на «больные» регионы/каналы.
4) Защита и комплаенс по умолчанию
mTLS внутри периметра + подписи запросов (HMAC/EdDSA), короткоживущие токены.
WAF/бот-защита, device-fingerprinting, velocity-правила.
Секреты в Vault/HSM, KMS-шифрование at-rest, токенизация чувствительных полей.
WORM-аудит: неизменяемый журнал изменений математики/лимитов/джекпотов.
RGS уважает data residency: PII/логи по регионам (EU/UK/BR…) с запретом кросс-региональных чтений.
5) Полная карта телеметрии: что и как мерить
5.1 Бизнес-метрики (игровые)
`bets_per_min`, `active_sessions`, `avg_bet`, `win_rate`, `hit_rate`, `rpt` (RTP фактический), `bonus_entry_rate`, `freespin_rounds`, `feature_buy_count`, `jackpot_contrib/trigger`, `settle_lag_ms` (время от исхода до кредита), `wager_progress`.
5.2 Технические метрики
Латентности p50/p95/p99 по `bet`, `settle`, `rollback`, `wallet.debit/credit`.
Error rate по эндпоинтам, типы ошибок (5xx/4xx/business).
Saturation: CPU/Memory/GC, queue depth, thread pool utilization.
Шина: lag per partition, consumer liveness, retry/backoff counters.
5.3 RG/AML/KYC-сигналы
`rg.limit.hit`, `rg.timeout.started/ended`, `self_exclusion.flagged`.
Velocity аномалии, общие устройства/карты (для антифрод-фидов), `aml.alert.opened`.
5.4 Категории логов
Аудит (WORM): изменение math, RTP-пула, лимитов, джекпот-параметров.
Интеграции: подписи, статус кошелька/агрегатора, причины ретраев.
Инциденты: таймкоды падений, контекст trace_id, «хвост» событий до/после.
6) Схемы событий и контракты
6.1 Базовые топики (Kafka пример)
6.2 Пример события `bet.settled`
json
{
"event_id": "uuid",  "event_type": "bet.settled",  "occurred_at": "2025-10-23T16:21:05Z",  "tenant_id": "brand-7",  "player_id": "p_19f3",  "round_id": "r_8c12",  "trace_id": "tr_a1b2c3",  "payload": {
"game_id": "studio:slot_forge_02",   "bet": {"amount": 1.00, "currency": "EUR"},   "win": {"amount": 14.60, "currency": "EUR"},   "bonus_state": {"in_bonus": true, "freespins_left": 7},   "jackpot": {"contrib": 0.01, "triggered": false}
},  "idempotency_key": "bet_r_8c12_1"
}Требования: Schema Registry (Avro/JSON), backward-compatible версии, строгие ключи партиционирования (`tenant_id`, `player_id`).
7) Дашборды и алертинг (что видеть «сходу»)
Игровой экран (NOC/продукт):- bets/min, settle_lag, RTP-факт/сертифицированный диапазон, hit_rate, jackpot latency.
- Тепловая карта по гео/провайдерам/играм, top error codes.
- p95 per endpoint, error rate, queue depth, consumer lag, CPU/mem, TLS errors.
- Wallet/aggregator health, retry storms, backoff effectiveness.
- p95 `settle` > целевого X минут подряд.
- error rate `bet/settle` > Y% в регионе/игре.
- lag шины > Z секунд.
- drift RTP за N минут > допустимого коридора (для быстрой диагностики).
8) Хаос-инжиниринг и учения
PSP/кошелёк офлайн: проверка саг/ретраев, блоков `no new sessions`.
Сетевые шторма/дубль-доставки: идемпотентность и дедупликация.
Замедление БД/кэша: back-pressure, graceful degradation.
Падение региона: RPO ≤ 5 мин, RTO ≤ 30 мин, синхронизация outbox.
9) Версионирование math и управление конфигом
Любое изменение математики/RTP — новая версия билда, сертификация, фриз старой ветки.
Конфиг-флаги (номиналы, лимиты, гео-запреты) — в версионированном хранилище, с «четырьмя глазами» и WORM-аудитом.
«Blue/Green» кат-овер ассетов (CDN) + канарейка на API.
10) Инциденты: от детекта до постмортема
1. Детект по SLO-алертам/аномалиям.
2. Деградация (stop-new-sessions, отключение спорной фичи, перевод на резервные воркеры).
3. Компенсации через саги/rollback, сверка с кошельком и джекпот-кошельками.
4. Постмортем: таймлайн, первопричина, действия, предотвращающие повтор (контроль флагов, контрактные тесты, лимиты).
11) Чек-лист студии (RGS) — стабильность и телеметрия
- Идемпотентность `bet/settle/rollback`, уникальные `bet_id`/`round_id`.
- Outbox/CDC везде; нет публикаций «в обход» транзакций.
- Саги на денежных путях; компенсирующие события вместо ручных правок.
- Back-pressure, очереди, лимиты по сессии/игре/региону; режим «no new sessions».
- Канареечные релизы/фичфлаги, авто-роллбек по SLO.
- Полный набор метрик и дашбордов; алерты по SLO-бюджету.
- WAF/mTLS, подписи, Vault/HSM, WORM-аудит.
- Хаос-учения (PSP офлайн, дубли событий, деградации БД).
- Версионирование math/RTP и управление конфигом «четыре глаза».
- Data residency: региональные логи/PII, запрет кросс-чтений.
12) Чек-лист оператора/агрегатора — что запросить у студии
- SLO и реальные дашборды p95/p99, error rate, settle lag, jackpot latency.
- Док-спеки API + схемы событий (Schema Registry), истории версий.
- Политика инцидентов/постмортемов, протоколы rollback/compensation.
- Доказательства идемпотентности (ключи дедупликации, тест-кейсы дублей).
- Канареечные релизы, фичфлаги, возможность instant off.
- WORM-лог изменений math/лимитов; доступы по RBAC/временным токенам.
- Data residency и гео-конфигурации, локальные отчёты и RG-хуки.
- Регулярные сверки джекпот-кошельков и кошелька платформы.
13) Красные флаги (анти-паттерны)
Ручные правки исходов/балансов в БД.
Публикация телеметрии без outbox/CDC (потерянные события).
Отсутствие идемпотентности → дубли сеттлментов.
Монолит без back-pressure: «шторм» кладёт весь RGS.
Нет канареек/фичфлагов, релизы только «big bang».
BI/регуляторные отчёты с боевой OLTP-БД.
Нет WORM-аудита изменений математики и джекпотов.
Стабильный RGS строится на строгих денежных инвариантах (идемпотентность, саги, outbox), управляемой производительности (очереди, back-pressure, канареечные релизы) и прозрачной телеметрии (контракты событий, дашборды SLO, WORM-аудит). Такой фундамент даёт студии и оператору уверенность: раунды честны и быстры, деньги защищены, отчётность достоверна, а инциденты — редки, коротки и понятны.
