How RGS - remote gaming servers work

RGS (Remote Gaming Server) is the "heart" of online casino games: here bets are accepted, math outcomes are counted, funds are withheld and debited, unchangeable logs are written for audit and compact payloads are given to the client (HTML5, nativ, live shows). Correct RGS combines: honesty (server-authoritative outcome), performance (low latency), idempotency and certifiability.

1) Basic architecture

1. 1 Logical layers

API gateway: authentication, rate limits, idempotent keys, routing by games/versions.

Game Core: state machine of the game, RNG calls, mapping of outcomes to symbols/payouts, feature rules (free spins, hold & spin).

Math Engine: pay tables, weights/strips, mouthguards, simulation assistants.

RNG Service: CSPRNG/PRNG with seed/stream policy, independent streams, HSM/secure seed storage.

Wallet Adapter: lock→settle transactions, idempotency, multicurrency/denominations, tax fields.

Promo/Tournaments: free rounds, missions, ratings; asynchronous collbecks.

Jackpot Service: local/network pools, mystery/progressive, firing rates, mouthguards.

Audit Log: WORM/Merkle chains, a transcribed format for laboratories.

Telemetry: product analytics (separate from audit), alerts and SRE metrics.

1. 2 Process stack (typical)

Kernel: Go/Java/Kotlin/Node. js (stateless), RPC: REST/gRPC/WebSocket (live-игры).

Repositories: PostgreSQL (transactions), Redis (caches/idempotency), Kafka/Pulsar (events).

Deploy: Kubernetes/Autoscaling, Multi-AZ, Blue/Green or Canary.

2) Spin life cycle (sequence)

1. Bet. Place

Клиент → RGS: `gameId, betAmount, currency, idempotencyKey, deviceInfo`.

RGS: validation of limits/geo/jurisdictions → 'wallet. lock(bet)`.

2. Outcome. Compute

RGS: `rng. draw () 'in the game stream → mapping numbers to characters/cells → calculating lines/clusters → features/bonuses.

3. Settle

RGS: `wallet. settle (-bet + payout) ', marks bonus credits/taxes, collects jackpot contribution.

4. Emit

Response to the client: compact outcome (character positions, payments by steps, timeline feature), checksum/signature.

5. Audit

Entry: '(request, seed/nonce, mathVersion, outcome, payout, walletTxId, merkleHash)' in unchangeable log.

💡 Retry with the same'idempotencyKey 'returns the same outcome and reference to the original transaction.

3) RNG and maths

3. 1 RNG

Seed/stream policy: separate streams for reels, bonuses, jackpot; disallowing re-use of seed.

Algorithms: CSPRNG (CTR/HMAC-DRBG) or high-quality PRNG (PCG/Xoshiro) for audit requirements.

Samples: only rejection sampling/alias (Vose), no '% N'.

Time to capture outcome: before animations/visual; timestamp and hash in the audit.

3. 2 Math Engine

Configs (JSON/DSL versioned): RTP breakdown, drum/weight stripes, mouthguards, retriggers, buy-feature (if allowed).

Invariants: non-negative payment, compliance with caps and limits, correct index boundaries.

Simulations: ≥10⁷ - spin 10⁸ per release; RTP/volatility/frequencies and p99 tails. 9 in tolerances.

Migrations: a change in mathematics → a new 'mathVersion', shifting of seeds and a mandatory regression package.

4) Wallet and transactions

4. 1 Contract

Two-phase scenario: 'lock (bet) → settle (net)'; idempotent keys and TTL.

Currencies/denominations: currency accuracy, rounding, rate fixing (if cross-rate).

Border cases: timeouts, partial failures - the game does not change the outcome; retaking the settle to success/compensation.

4. 2 Idempotency

The key is formed from '(playerId, gameId, roundId	clientNonce)`.
Repeat → return the previously calculated payload and walletTxId; no double write-offs.

5) Promo, freespins, tournaments

Free Rounds API: issuing spin packs, 'PromoWallet' (accounting for bonus funds separately), write-offs priority.

Missions/events: synchronous metrics in Telemetry + asynchronous collecks in CRM/mission engine.

Tournaments: publishing events on stream ('score: update'), idempotent-ingest at the leader board.

6) Jackpots

Types: local fix/progressive, network progressives, mystery.

Model: share of bet → pool; triggers - probabilistic/range/timer; mouthguards/floors; anti-sniping.

Consistency: multi-region pool consistency (CRDT/two-phase commit), separate audit.

7) Logs, audit and compliance

WORM: write-once-read-many, merkle chains, hash signatures of log packages.

Split: Audit (legally significant records) ≠ Telemetry (product/performance).

Replays: playing a round by '(seed, step, mathVersion)'.

Reporting: GLI/eCOGRA/BMM formats; Export by regulatory API/file retention policies.

8) Security and privacy

Authentication: JWT/MTLS between the platform and RGS; response signatures.

Tenant isolation: multi-tenant, domain/key limits, individual RNG pools.

CSP/DoS protection: limits, canary keys, "cold" locks by geo/jurisdiction.

PII minimization: store only the necessary identifiers; encryption "at rest" and in the channel.

Change-control: 4-eye math release, signed artifacts, hash manifestos.

9) Scaling, fault tolerance, regions

Stateless core: horizontal autoscale; sticky-sessions only for the period of complex bonuses (by token).

Multi-AZ/Multi-Region: asset-asset for reads/telemetry, asset-liability or conflict-free for wallet/jackpots.

Quotas: TPS per-game/per-tenant, wallet connection pools, backpressure.

Disaster Recovery: RPO/RTO target, replication logs, regulated switchover/drill plan.

10) Monitoring and SRE

SLO/SLA: p95/p99 for 'Spin', settle error, wallet timeouts, crash-free rate live scenes.

Metrics: TPS by games, RTP deviation from the benchmark (control cards), bonus frequency, wallet latency, overheating of RNG pools.

Performance logs: slow-query, GC/heap, queues.

Alerts: RTP/frequency deviation, 5xx height, idempotent keys stuck, jackpot drift.

11) RGS interfaces (minimum contract)

11. 1 Spin API (simplified scheme)

json
POST /v1/games/{gameId}/spin
{
"playerId": "p-123",  "roundId": "r-456",  "stake": { "amount": 100, "currency": "EUR" },  "idempotencyKey": "p-123:r-456:1",  "context": { "jurisdiction": "MT", "device": "web", "promo": "FR-25" }
}

Response

json
{
"outcome": {
"symbols": "...compact-encoded...",   "wins": [{ "line": 7, "amount": 250 }],   "features": [{ "type": "freespins", "awarded": 10 }]
},  "payout": { "amount": 150, "currency": "EUR" },  "walletTxId": "wt-789",  "mathVersion": "1. 8. 2",  "auditHash": "merkle:abc..."
}

11. 2 Free Rounds

`POST /promo/freerounds/issue`

'POST/promo/freerounds/consume '(idempotent; bonus wallet accounting)

11. 3 Jackpot

`POST /jackpot/contribute`

'POST/jackpot/try-win '(atomic with settable)

12) Jurisdictions and RG (Responsible Gaming)

Ficheflags: disabling auto-spins/buy-feature, speed, minimum RTP - at the game level and RGS.

RG signals: deposit/time limits, "reality checks," self-exclusion - RGS respects platform stop flags.

Marketing gate: Do not send promotional collbacks to players in RG modes.

13) Performance: Benchmarks

Targets: p95 Spin API ≤ 60-120 ms (without external providers), p99 ≤ 200-300 ms; Settle error <10⁻⁴.

Savings: compact payloads (bit-packing), caching of unchangeable configs, pre-warm RNG, butch collbecks of missions.

Tests: loading (step/chaos), soak-day/week, GC profiling and allocations.

14) Frequent errors and anti-patterns

'% N' while mapping → bias. Use alias/rejection.

The decision of the outcome on the client → disputes/tamper/failure of certification.

The mixing of Audit and Telemetry → the inability to prove correctness.

Lack of idempotency → duplicate payments in case of retrays.

Total RNG flow for the entire → hidden correlations.

Changing mathematics "on the fly" without versioning → unreliable logs/strikes from regulators.

Long external RPCs in the critical spin path → peak leitenses/timeouts.

15) RGS Implementation Roadmap (reference 12-20 weeks)

1. Discovery: Platform/Jurisdictional Requirements, SLAs, Wallet/Jackpot Integrations.

2. MVP architecture: stateless core, RNG/Math, WalletAdapter, Audit.

3. Game core: state machine, DSL configs, replays.

4. Idempotence/transactions: purse contracts, rejection tests.

5. Promo/jackpots: integrations and anti-sniping.

6. Security: signatures, WORM, accesses, multi-tenant.

7. Load/simulations: 10⁸ -sims, LT/soak, chaos tests.

8. Certification: RNG package/math/logs, dry-run exports.

9. Canary: 1-5% traffic, guardrails (RTP drift, frequencies, 5xx).

10. Scaling and DR: multi-region, switchover development.

16) RGS Large Checklist

Honesty and mathematics

Server-authoritative outcome, fix before animation
Independent RNG streams, alias/rejection, seed policy
≥10⁷ simulations - 10⁸; RTP/frequency/tail tolerances

Transactions

Lock→Settle, idempotent keys, retrays are safe
Multicurrency/denominations, taxes, reporting
Jackpot is atomic with a settle

Audit and Replay

WORM/Merkle Chains, Lab Export
Replay by '(seed, step, mathVersion)'
Split Audit/Telemetry

Safety

MTLS/JWT, response signatures, secrets in HSM/manager
Multi-tenant isolation, rate limits, DoS protection
PII minimization, encryption, access-policies

Performance

p95/p99 SLA, autoscaling, backpressure
Compact payloads, caches, hot RNG pools
Load/soak/chaos tests

Jurisdictions and RG

Regions ficheflags, minimum RTP/speeds
RG stops/limits/self-exclusion respected
Transparent Promo/Freespin Rules

RGS is a combination of cryptographically correct randomness, deterministic mathematics, reliable transactions and auditable logs. The architecture wins, where the outcome is fixed to the visual, transactions are idempotent, logs are unchangeable, and the platform scales horizontally and meets regulatory requirements. Such RGS makes games fair, fast and sustainable - from the first bet to the billion-dollar spin.