Casino core architecture: layers, modules, data buses

Full article

💡 18+. The material is educational. Not a call to play. The goal is to show an engineering "terrain map" for building or auditing the iGaming core.

1) The whole picture: what casino core consists of

Casino core is a set of domain services that provide registration/identification of players, acceptance/storage of money, calculation of bets, bonus economy, risk control and compliance with regulations. In the diagram from top to bottom:

1. Edge layer (outer perimeter): API gateway, WAF/bot protection, rate limiting, service mesh ingress, geo/legal filters.

2. Domain-слой (бизнес-логика): PAM, Wallet/Ledger, Bonus Engine, Cashier/PSP Orchestration, Game Sessions, Risk/Anti-Fraud, RG, Jackpot/Tournaments, Affiliates, CRM/Notifications, Compliance/Reporting.

3. Data/Integration layer: event buses (Kafka/Pulsar), queues (SQS/Rabbit), CDC/Outbox, ETL/ELT (in BI showcases), Feature Store/ML, caches (Redis), OLTP DB (Postgres/Oracle), OLAP (ClickHouse/BigQuery).

4. Observability & SecOps: metrics/tracing/logs, SIEM/SOAR, secrets (Vault/HSM), keys and tokens, RBAC/ABAC, audit log (WORM).

2) Domain modules (minimum required composition)

2. 1 PAM (Player Account Management)

Registration/login, SSO, session and device management, KBA/2FA.

Profile: age/geo/currency/segments, RG/self-exclusion statuses.

Restrictions: access to games by jurisdiction, bans, "reality checks."

2. 2 Wallet/Ledger (money circuit)

Multicurrency accounts, double entry (debit/credit), immutable transactions.

Atomic betting and winning transactions (idempotency keys, exactly-once within a domain).

Holds under active backs/rounds; jackpot transit accounts.

Interaction only through commands (command API), reading - through projections (CQRS).

2. 3 Cashier / PSP Orchestration

Routing payments by geo/bin bands/scoring; cascading in case of failures.

3-DS/AVS/velocity-rules; tokenization of cards; on-/off-ramp for crypt.

SLO set: authorization ≤ 3c p95, total deposit success ≥ 85% geo.

2. 4 Game Sessions (ISP integrations)

Creation of game sessions (token handshake), validation of country/currency/age.

stavka→iskhod→settlment events go on the bus; RNG and settlement are on the side of the provider.

Anti-abuse: min bet, spin frequency, prohibition of changing the face value "inside the trick."

2. 5 Bonus Engine

Bonus states (issued/locked/active/forfeit), vager, game contribution, max bet/max cashout, deadlines.

Missions/quests, freespins, cashback; tournament/jackpot compatibility.

Strict validity of rules at the time of bet; unchangeable history.

2. 6 Risk / Anti-Fraud

Behavioral cues (bet rate, multi-accounts, shared devices/cards).

Velocity rules, graph checks of connections, chargeback defense.

Reactions: soft (limits), hard (block/escalation in AML).

2. 7 Responsible Gambling (RG)

Deposit/loss/bet/time limits, timeouts, self-exclusion.

"Reality checks" and forced pauses; storage of consents and logs.

2. 8 Jackpots & Tournaments

Local/network, fix/progressive; share fee with each rate.

Public leaderboards; independent verification of results; anti-bot.

2. 9 Affiliates & CRM

Sub-ID tracking, attribution (CPA/RevShare/Hybrid), post-backs.

Segmentation, triggers, suppression rules, omnichannel (push/e-mail/SMS).

2. 10 Compliance & Reporting

Regulatory offloads, tax reports, SAR/STR; WORM audit log.

Data residency by jurisdiction (EU/UK/BR, etc.).

3) Event model and data buses

3. 1 Basic topics (example of Kafka naming)

`player. registered`, `player. kyc. status. changed`

`wallet. debit. requested/committed/failed`, `wallet. credit.`
`game. session. started/ended`, `bet. placed`, `bet. settled`
`bonus. issued/consumed/forfeited`, `wager. progress. updated`
`rg. limit. hit`, `rg. timeout. started/ended`
`cashier. deposit. requested/succeeded/failed`, `withdrawal. requested/sent`
`risk. alert. raised/closed`, `aml. case. opened`
`jackpot. contribution/triggered`, `tournament. score. updated`

Contracts: Avro/JSON Schema + Schema Registry, versioning (backward compatible), strict idempotence keys.

3. 2 Event template (simplified)

json
{
"event_id": "uuid",  "event_type": "bet. settled",  "occurred_at": "2025-10-23T16:09:12Z",  "tenant_id": "brand-1",  "player_id": "p_123",  "session_id": "s_456",  "trace_id": "t_abc",  "payload": {
"game_id": "provider:slot_777",   "bet_amount": {"amount": 2. 00, "currency": "EUR"},   "win_amount": {"amount": 36. 40, "currency": "EUR"},   "bonus_impacted": true
}
}

Rule: events are immutable; adjustments - by separate compensating events.

3. 3 Outbox & CDC

All domain transactions write an event to the outbox in the same database → the background publisher sends it to the bus.

CDC (Debezium and analogs) - for secondary flows in DWH without load on OLTP.

4) Consistency, sagas and idempotency

Sagas for long processes (deposit/cashout, verification, tournament awards).

The idempotency of all commands is'Idempotency-Key '+ service-side deduplication.

Consistency strategy: in the wallet - strictly (ACID), otherwise - eventual (through projections).

Compensations: individual domain events, prohibition of "manual edits" in the ledger.

5) Data: OLTP/OLAP, caches, projections

OLTP: Postgres/Oracle for wallet, PAM, bonuses (p95 <150ms).

Caches: Redis for sessions, limits, hot projections of leaderboards.

OLAP: ClickHouse/BigQuery — витрины KPI (FTD, NGR, ARPPU, Retention, LTV, Wager progress, Risk flags).

Projections (CQRS): quick player/transaction search (<2c), real-time RG panel/risk.

6) Payment orchestration: more detailed

Routing rules: geo, BIN, risk rate, load, cost.

Cascade: PSP1 → PSP2 without losing the basket; retreats with exponential pause.

Reconciliations: daily PSP reports → wallet register; auto discrepancies → tickets.

7) Integrations with game providers

Gateway pattern: a single Game API, currency/feature mapping, health check with degradation.

Settlement: incoming provider collback → wallet domain command. settle with idempotency key.

Interlocks: minimal; bet/win - atomic pair of transactions.

8) Observability and SLO

Метрики: p95/p99 latency per service, error rate, saturation, business KPIs (bets/min, settle lag, deposit success).

Trace trace_id end-to-end (edge→domeny→shina→konsyumery).

Logs: structured, with PII editing.

SLO minimum:

Core uptime ≥ 99.95%
p95 wallet <150 ms
Lost/duplicated settlements = 0
Event delay time to BI <5 min

9) Safety and compliance

Zero-trust: mTLS inside mesh, short-lived tokens, RBAC/ABAC, least rights principle.

Secrets: Vault/HSM, key rotation, KMS data encryption "at rest."

PCI DSS/GDPR/local analogues: segmentation of environments, PAN tokenization, DLP, access log (WORM).

WAF/bot protection: filters on behavioral signals, device-fingerprinting.

Data residency: shardiness by region; cross-regional PII ban.

10) Availability, DR and release version

Asset-asset/asset-liability by region; RPO ≤ 5 min, RTO ≤ 30 min.

Canary releases/feature-flags, rollbacks; database migrations - via ghost/secondary indexes.

Chaos engineering: regular network/PSP/provider files to check degradation.

11) Schema and data quality management

Data contracts: event versioning (semver), producer/consumer contract tests.

Governance: data catalog, source trust level, storefront update SLA.

Quality: deduplication, late arrivals, idempotent upserts in OLAP.

12) Roles and access (Back-office)

RBAC: clear roles (finance, risk, support, marketing, compliance).

Crete actions: confirmations of "4 eyes," a log of unchangeable operations.

PII screen: masking; full access - by application/temporary tokens.

13) Casino core maturity metrics (self-esteem)

1. Reliability: wallet/cash register/session SLOs are performed ≥ 99% of days.

2. Data: events hit BI ≤ 5 min; consistency ledgers vs PSP ≥ 99.99%.

3. Bonuses: rule designer without database edits; audit of changes.

4. RG/AML: real-time signals; reports/uploads are automated.

5. Incidents: MTTR <30 min; postmortems are public internally.

6. Testing: contract, load, chaos tests; provider/PSP test sandboxes.

14) Architecture Auditor Checklist

There is an outbox/CDC, the event is published atomically with the transaction.
The ledger is implemented as an immutable posting book; there is a reconciliation with the PSP.
All commands are idempotent; there is key deduplication.
Separate OLTP and OLAP; projections do not hit combat databases.
RG limits are applied synchronously at the rate; reality-check is enforced.
Game gateway degrades to read-only/" no new sessions" in incidents.
DR plan is regularly exercised; backups are checked by recovery.
Key/secret policy and rotation is documented.
Compliance reports are collected automatically (without Excel manual work).
Audit logs - WORM, least rights access.

15) Anti-patterns ("red flags")

Manual edits of balances and bonuses in the database.

Mixing public and private API, lack of API gateway.

Recording events "bypassing" domain transactions (not through outbox).

Monolithic wallet and bonuses without idempotency and sagas.

Unified database "for everything" + BI requests according to the combat scheme.

Lack of event versioning and contract tests.

There is no register of changes to bonus rules and tournament formulas.

Payment failures without cascade; "try later" as a strategy.

No RG tools out of the box; license on trusts.

Casino core is an event-based, strictly limited by rights "network" of services where money and responsibility are primary. Strong architecture rests on three pillars:

1. Hard integrity of money (ledger, idempotence, sagas, outbox/CDC), 2. Event and observability (contracts, tracing, SLO, BI showcases), 3. Default security and compliance (zero-trust, PCI/GDPR, RG/AML).

Having built these foundations, the operator scales content, bonus economics and marketing without risk to the main thing - players' money and brand reputation.