How casino backend architecture works

1) The whole picture: domains and data streams

Key domains:

Identity & Accounts - registration, authentication, roles, devices, sessions.
Wallet & Ledger - cash accounts, bonus wallets, transactions, ledger (append-only).
Gaming & Bets - game sessions, bets, rounds, calculation of outcomes, integration (RNG/Live/Crash, etc.).
Bonuses & Promotions - freespins, cashback, vouchers, wagering (wagering), anti-abuse.
Payments (Cashier) - on-ramp/off-ramp: maps, APM, crypt/stablecoins, KYC binding.
KYC/AML/KYT & RG - Identity/Address/Revenue Verification, Transaction Screening, Limits and Timeouts.
Risk & Compliance - limits of rates/payments, sanctions lists, geo-blocking, audit.
Catalog & Lobby - a list of providers, games, categories, limits; A/B variants.
Reporting & BI - P&L, GGR/NGR, retention, player life cycle, affiliates.
Observation & Ops - logs, metrics, traces, alerts, fraud signals.

Orchestration: a modern platform is built event-driven: services exchange events via the bus (Kafka/NATS), critical operations are linearized (wallet/ledger), side subsystems are signed and responded asynchronously (bonuses, BI, notifications).

2) Layered model

Edge layer: API gateway, WAF/bot protection, rate limits, geo/IP filters, feature flags.

Service layer: autonomous microservices by domain; synchronous contracts - only where instant consistency is needed (e.g. wallet debit at bet).

Event bus: main business events ('bet. placed`, `round. settled`, `bonus. issued`, `kyc. verified`, `payout. requested`).

Data: OLTP (Postgres/MySQL) for transactions; KV/Cache (Redis) for sessions/limits; object storage (S3) for logs and export; OLAP (ClickHouse/BigQuery) for analytics.

3) Wallet and ledger: the heart of the platform

Principles:

Append-only ledger: each financial transaction is a record with type, amount, currency, reference to the source (rate, bonus, deposit).
Cash and bonus balances are posted. You cannot "mix" money and bonuses; uses a funding source policy.
Atomicity of debet→kredit: rate = debit of money or bonus wallet + creation of hold; round calculation removes hold and makes a credit/debit on the result.

Example of rate transactions:

`LEDGER: HOLD` (−10. 00 EUR, source: cash, ref: betId)
`LEDGER: SETTLE_DEBIT` (−10. 00 EUR) + `LEDGER: PAYOUT` (+36. 00 EUR) - if WIN
`LEDGER: HOLD_RELEASE` (+10. 00 EUR) - if VOID/PUSH

Requirements:

Idempotent operations (idempotence keys by 'requestId').
Optimal locking to protect against racing.
Clear calculation currency and fixing rates for conversions.

4) Integrations with game providers

Wallet patterns:

Seamless - operator's balance; bet/settlement goes through our API in real time.
Transfer - deposit to the game bank from the provider; more friction, but lower purse uptime requirement.

Synchronous paths (critical):

`bet. place '→ pre-auth in the wallet (hold) →' accepted/rejected '.

Asynchronous paths:

`round. settle 'from the provider (webhook/WS) → settle in the ledger → an event to the bus → reporting/bonuses.

Standardization via bridge: uniform event schemas and'roundId/betId 'identifiers, limit mapping table and side-bets, error normalization.

5) Bonuses, wagering and anti-abuse

Models: deposit bonuses, freespins, returns (cashback), missions, tournaments.

Wagering: wagering progress stored separately; "what bets count" rule (percentages by game category).

The order of write-off: first bonus funds, then real - or vice versa, strictly according to policy.

Anti-patterns of the player: bets on opposite outcomes, minimum bets for farm progress, transfer between games with different weights - caught by rules and scoring.

6) KYC/AML/KYT и Responsible Gaming (RG)

KYC: ID/address/age verification; statuses control limits (deposit/within/betMax).

AML/KYT: screening of payment channels and on-chain addresses (for crypt), sanctions lists, sources of funds.

RG: daily/weekly limits, timeouts, self-exclusion; blocking checks are performed before'bet. place` и `payout. request`.

7) Cash: deposits and payments

Deposits: card/AWS providers, crypto/stables, local methods; webhook confirmations; protection against chargeback risks.

Payments: queues, limits, 4-eye principle for large amounts; sources of funds → "cash balance only."

On-ramp/off-ramp crypts: auto-conversion, KYT addresses, exposure hedging.

8) Limits, risk and regional rules

Limit profiles ('DEFAULT', 'VIP _ A', 'VIP _ B', 'ULTRA') by country/currency/ACC.

Geo-blocking by IP/GPS/document.

Overlaps by game/category, provider bans in jurisdictions.

Reaction to anomalies: bursts of bets, correlation of devices/payments, a lot of "VOID" from one user.

9) Observability and operation

Metrics: wallet delays, bet failure, round calculation time, depozita→stavka conversion, GGR/NGR, SLA payout, share of bonus bets.

Logs and traces: correlation 'traceId' in all events; storage of raw events in "cold" storage.

Alerts: wallet response degradation, 'VOID' spike, reconcile report error, 'RG _ BLOCKED' growth.

Runbooks: clear incident procedures (provider drop, ledger out of sync, rounds canceled).

10) Security and privacy

Auth: short-lived JWT/opaque tokens, key rotation ('kid'), mTLS to critical integrations.

Access policies: strict separation of roles (operations, finance, support), 2FA; for large payments - okay from the second person.

Data privacy: PII encryption, payment data tokenization, storage minimization; GDPR/deletion on request.

Audit: unchangeable logs, signature of critical events, export for the regulator.

11) Scalability and fault tolerance

Statles services behind the auto-scaler; horizontal shard for hot tables (rates, event logs).

Ledger - vertical margin + replication for reading/reporting; "freezing" migration schemes through shadow tables.

Caching: Redis with TTL and "two-check" strategies (read-through + invalidate by events).

DR/HA: multi-AZ, backups with regular recovery, RPO/RTO at the level of regulatory requirements.

Degradation modes: autonomous checkout, disabling "heavy" bonuses, transferring live games to maintenance when the bus is unavailable.

12) Contracts and Examples

Bet (sync, JSON/REST or gRPC):

json
POST /bets/place
{
"requestId": "9a7f-…",  "playerId": "p_123",  "wallet": "cash",
"roundId": "R-2025-10-17-19:20:05-PRAGM-Table12",  "gameId": "pragm_live_roulette",  "selection": [{"market":"straight","value":"17"}],  "stake": {"amount":"10. 00","currency":"EUR"},  "device": {"ip":"203. 0. 113. 5","ua":"Mozilla/..."}
}

Answer:

json
{
"status": "ACCEPTED",  "betId": "bet_8cd…",  "balanceAfter": "245. 30",  "hold": "10. 00",  "limits": {"maxBet":"5000. 00"}
}

Bus event (async):

json
{
"event":"round. settled",  "roundId":"R-2025-10-17-19:20:05-PRAGM-Table12",  "bets":[{"betId":"bet_8cd…","outcome":"WIN","stake":"10. 00","payout":"360. 00"}],  "playerId":"p_123",  "ts":"2025-10-17T19:20:09. 231Z",  "traceId":"tr_5f1…"
}

13) Anti-patterns (which breaks the platform)

Mix bonus and cash in a single transaction with no sources.

Long-lived tokens and storing them on the client.

Lack of idempotency in critical operations (debit doubles).

Monolithic reporting SQL for combat database (OLAP vs. OLTP).

Blind power of attorney to the provider without reconcile and limits.

No time zone standard (UTC everywhere!) in round identifiers and reports.

Synchronous calls in non-financial domains (bonuses/notifications) block the bet.

14) Casino backend launch checklist

Finance and wallet

Ledger append-only, idempotency, balance version.
Cash/bonus separation, source policy.
Rates/conversions are captured in the transaction.

Game integrations

Single rate/settlement contract, 'roundId/betId' format.
Seamless wallet by default; Transfer - only where justified.
Automatic VOID/REFUND scripts.

KYC/AML/RG

Policies prior to admission to rate/pay; KYC statuses ↔ limits.
KYT for on-chain, sanction screening, evidence storage.

Cash desk

Webhooks/signatures, doubles/retrays, reconcile with PSP/crypto providers.
4-eyes on large payouts, operator activity log.

Observability

Wallet metrics, round-settle latency, bid failure, payout SLAs.
Traces are end-to-end (traceId), alerts, runbooks.

Safety

mTLS/HMAC, JWT with short TTL, key rotation.
Roles/rights, 2FA, payment data tokenization.

Data

OLTP/OLAP separation, CDC to DWH, S3 for raw events.
Backups and regular recovery tests.

15) The bottom line

The backend casino architecture is a strict core of money and bets with linear consistency and flexible peripherals on events: bonuses, analytics, communications. Success is determined not by the number of microservices, but by discipline: clear domain boundaries, a ledger without "magic," idempotency, observability and compliance by default. With this foundation, the platform scales across countries/currencies/providers and withstands loads without compromises on security and money.