Як RGS забезпечує стабільність і телеметрію слотів

Повний текст статті

💡 18+. Технічний матеріал для команд студій, агрегаторів і операторів iGaming. Не заклик до гри.

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 приклад)

`game. session. started	ended`
`bet. placed`, `bet. settled`, `bet. rollback`
`bonus. issued	consumed
`jackpot. contribution	triggered`
`rg. limit. hit`, `rg. reality_check`
`wallet. debit. requested	committed

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.

Техекран (SRE):

p95 per endpoint, error rate, queue depth, consumer lag, CPU/mem, TLS errors.
Wallet/aggregator health, retry storms, backoff effectiveness.

Алерти (SLO-бюджет):

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-аудит) Такий фундамент дає студії і оператору впевненість: раунди чесні і швидкі, гроші захищені, звітність достовірна, а інциденти - рідкісні, короткі і зрозумілі.