How RGS provides slot stability and telemetry

Full article

💡 18+. Technical material for studio teams, aggregators and iGaming operators. Not a call to play.

1) Role of RGS in stability and transparency

RGS (Remote Game Server) is the core of the studio's RNG content. It generates round outcomes, maintains bonus states, integrates with the platform/aggregator payment loop, and supplies telemetry for BI and regulators. The following depends on its stability: the absence of doublets of settlements, the low latency of the round, the correctness of jackpots/missions and the reliability of reporting.

2) Target SLOs and invariants over money

Business SLO (minimum):

p95 'bet/settle' <200 ms (without payment hops), error '<0. 1%`.
"Lost/Duplicated Settlements" = 0.
Delivery of events to the bus/BI ≤ 5 min.
Availability of the critical API (bet/settle/rollback) ≥ 99. 95%.

Invariants:

True by balance - at the platform wallet, RGS stores only the state of the rounds.
All monetary calls are idempotent: 'Idempotency-Key', unique 'bet _ id '/' round _ id'.
Compensation - sagas, not "manual edits" of the database.

3) "Anti-fragile" stability architecture

3. 1 Idempotence and sagas

Commands' bet. authorize`, `bet. settle ',' rollback 'with idempotency key and deduplication.

The saga "bet → outcome → credit" with clear statuses ('started', 'settled _ pending _ credit', 'credited', 'compensated').

3. 2 Outbox/CDC and Guaranteed Delivery

The event is recorded in the outbox in one transaction with a change in the round state.

Background publisher → bus (Kafka/Pulsar); for DWH - CDC (Debezium/analogues).

3. 3 Back-pressure and queues

Buffering 'settle '/' jackpot. trigger 'in queues; protection against "betting storms."

Token buckets/limits on 'session _ id' and provider; graceful-degradation "no new sessions."

3. 4 Canary releases and feature flags

1-5% of traffic to the new version, auto-rollback via SLO.

Inclusion of controversial mechanics (Bonus Buy, new RTP pools) - via feature flag with instant off.

3. 5 State and Scale

The gaming state is minimal; sticky sessions by 'session _ id' or external stack (Redis/SQL) with TTL + jitter.

Horizontal scaling of 'settle '/' jackpot' workers regardless of API fronts.

3. 6 Health integrations

Health samples of the provider/aggregator: 'ping', 'config', 'wallet' latency.

Automatic load reduction on "sick" regions/channels.

4) Default protection and compliance

mTLS inside perimeter + request signatures (HMAC/EdDSA), short-lived tokens.

WAF/bot protection, device-fingerprinting, velocity rules.

Secrets in Vault/HSM, KMS encryption at-rest, tokenization of sensitive fields.

WORM audit: immutable journal of math/limit/jackpot changes.

RGS respects data residency: PII/logs by region (EU/UK/BR...) with a ban on cross-regional readings.

5) Full telemetry map: what and how to measure

5. 1 Business Metrics (Gaming)

'bets _ per _ min ',' active _ sessions', 'avg _ bet', 'win _ rate', 'hit _ rate', 'rpt' (RTP actual), 'bonus _ entry _ rate', 'freespin _ rounds', 'feature _ buy _ count', 'jackpot _ tribe/trigger', 'settle _ lag _ ms' (time from outcome to credit), 'wager _ progress'.

5. 2 Technical metrics

Latencies p50/p95/p99 by 'bet', 'settle', 'rollback', 'wallet. debit/credit`.

Error rate by endpoints, error types (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 signals

`rg. limit. hit`, `rg. timeout. started/ended`, `self_exclusion. flagged`.

Velocity anomalies, common devices/cards (for anti-fraud feeds), 'aml. alert. opened`.

5. 4 Categories of logs

Audit (WORM): change math, RTP pool, limits, jackpot parameters.

Integrations: signatures, wallet/aggregator status, reasons for retraces.

Incidents: fall timecodes, trace_id context, before/after event tail.

6) Event patterns and contracts

6. 1 Basic topics (Kafka example)

`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 Example of a'bet event. 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"
}

Requirements: Schema Registry (Avro/JSON), backward-compatible versions, strict partition keys ('tenant _ id', 'player _ id').

7) Dashboards and alerting (what to see "right away")

Game Screen (NOC/Product):

bets/min, settle_lag, RTP-actual/certified range, hit_rate, jackpot latency.
Heat map for geo/providers/games, top error codes.

Technical screen (SRE):

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

Alerts (SLO budget):

p95 'settle'> target X minutes in a row.
error rate'bet/settle '> Y% in region/game.
lag bus> Z seconds.
drift RTP in N minutes> valid corridor (for quick diagnosis).

8) Chaos engineering and drills

PSP/wallet offline: checking sagas/retras, blocks' no new sessions'.

Network storms/double deliveries: idempotence and deduplication.

Database/cache slowdown: back-pressure, graceful degradation.

Region drop: RPO ≤ 5 min, RTO ≤ 30 min, outbox synchronization.

9) Math versioning and config control

Any change in mathematics/RTP - a new version of the build, certification, frieze of the old branch.

Config flags (denominations, limits, geo-prohibitions) - in a versioned storage, with "four eyes" and WORM-audit.

"Blue/Green" cut-over assets (CDN) + canary on API.

10) Incidents: from detection to postmortem

1. Detection by SLO-alerts/anomalies.

2. Degradation (stop-new-sessions, disabling controversial features, switching to backup workers).

3. Compensation through sagas/rollback, reconciliation with wallet and jackpot wallets.

4. Postmortem: timeline, root cause, actions that prevent repetition (flag control, contract tests, limits).

11) Studio Checklist (RGS) - Stability and Telemetry

Identity 'bet/settle/rollback', unique 'bet _ id '/' round _ id'.
Outbox/CDC everywhere; there are no publications "bypassing" transactions.
Sagas on Money Ways; compensating events instead of manual edits.
Back-pressure, queues, session/game/region limits; "no new sessions" mode.
Canary releases/feature flags, auto-rollback on SLO.
Full set of metrics and dashboards; alerts on the SLO budget.
WAF/mTLS, signatures, Vault/HSM, WORM audit.
Chaos exercises (PSP offline, event doubles, DB degradation).
Math/RTP versioning and four-eye control.
Data residency: regional logs/PII, cross-reading inhibit.

12) Operator/aggregator checklist - what to request from the studio

SLO and real dashboards p95/p99, error rate, settle lag, jackpot latency.
API docks + Schema Registry, version histories.
Incident/postmortem policy, rollback/compensation protocols.
Evidence of idempotency (deduplication keys, duplicate test cases).
Canary releases, feature flags, instant off capability.
WORM log of math changes/limits; RBAC/temporary token accesses.
Data residency and geo-configurations, local reports and RG hooks.
Regular jackpot wallet and platform wallet reconciliations.

13) Red flags (anti-patterns)

Manual edits of outcomes/balances in the database.

Publish telemetry without outbox/CDC (lost events).

Lack of idempotency → duplicate settlements.

Monolith without back-pressure: "storm" puts all RGS.

No canaries/feature flags, only "big bang" releases.

BI/regulatory reports with OLTP combat database.

There is no WORM audit of math changes and jackpots.

Stable RGS is built on strict monetary invariants (idempotence, sagas, outbox), managed performance (queues, back-pressure, canary releases) and transparent telemetry (event contracts, SLO dashboards, WORM audits). Such a foundation gives the studio and the operator confidence: the rounds are honest and fast, the money is protected, the reporting is reliable, and the incidents are rare, short and understandable.