Why casinos are switching to modular architecture

Why casino modularity

The historical monolith slows down growth: each change pulls the release of the entire system, the integration of providers and PSP hit SLOs, compliance updates - throughout the code. The modular architecture (domain-driven + contract API + events) allows:

Quickly display features and connect providers without coordinating "everyone with everyone";
Scale selectively (live video separately from the cash register, wallet separately from the game catalog);
Isolate risks (an error in the promo does not bring down the wallet);
Comply with licenses (logging/versions/policies within domain boundaries);
Reduce TCO through clear contracts, reuse and automation.

Domain map (breakdown example)

Wallet/Ledger - money, currency hedge, bonus balances, PITR, audit.

Cashier/Payments - PSP, on-ramp/off-ramp, KYT, idempotent webhooks.

Gaming Bridge - provider adapters, round/bet normalization.

Catalog/Lobby - games, providers, features and display rules.

Promo/Bonus - stock rules, vouchers, wager.

KYC/AML/RG - identity verification, sanctions/PEP, limits and self-exclusion.

Experience - frontend, CDN, i18n, A/B, Telegram WebApp.

Telemetry/Analytics - events, showcases, ML/AI.

Compliance & Audit - MGA/UKGC reports, WORM archive.

💡 Each module has its own data schema, API and event contract; interaction - via the event bus and strictly versioned interfaces.

Modular architecture principles

1. DDD boundaries (bounded context). Clear knowledge of data and logic.

2. API-first + events. OpenAPI/AsyncAPI, JSON-Schema, contract tests.

3. Versioning and compatibility. 'v1 → v1. 1 → v2` (expand→migrate→contract).

4. Idempotency & Exactly-once-intent. Request keys, event deduplication.

5. Default security. mTLS, HMAC signatures, short JWT, RBAC/ABAC.

6. Independent releases. Canary/blue-green deploy, "two-writer" migrations are prohibited.

7. Observability. End-to-end 'traceId', SLO metrics per module.

8. Ficha flags. Traffic/geo/user segments, safe rollbacks.

Integration layer: how to connect providers and PSP

Adapter/Bridge pattern: each game/payment provider is a plugin with a single platform contract.

Games: normalization'roundId/betId/status', error mapping, limit cache.

Payments: a single interface 'authorize/capture/refund/payout', webhooks with idempotency.

Disconnectability - The faulty adapter is moved to maintenance without affecting others.

Sample contract (OpenAPI fragment):

yaml post /wallet/debit:
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/DebitRequest@v1'
responses:
'200': { $ref: '#/components/schemas/DebitResult@v1' }
'409': { description: IDEMPOTENT_REPLAY }

Events as "circulatory system"

Bus (Kafka/NATS) Event →:

`bet. placed`, `round. settled`, `payout. requested/approved`, `kyc. verified/failed`, `rg. limit_set`, `bonus. issued/consumed`, `cashier. webhook. received`, `wallet. hold/release`, `alert. slo_breach`.

Rules:

Events do not cancel the past; adjustments - by separate compensating events.
Each module writes only its original events, derivatives - as new topics.

data: layers and consistency

OLTP per module: Postgres/MySQL/KeyDB - isolated transactions.

OLAP/storefronts: ClickHouse/BigQuery are built from events; OLTP and analytics do not mix.

Feature Store/ML: OLTP independent layer with feature and TTL versions.

Consistency: strategically eventual between modules, and for money - local ACID + idempotent actions at the borders.

Deploy and scaling

Containers (Docker/K8s): autoscale modulo (wallet - CPU/IO; live video - network; bridge — RPS).

Perimeter isolation: network policies, individual secrets/keys per module, different PII/money/telemetry stores.

Traffic shaping: feature flags, canary share, regional routes.

DR/HA: Multi-AZ; asset-liability for money, asset-asset for readings/media.

Compliance is "sewn" into the modules

KYC/AML/RG is a proprietary module with policies and a solution log ('policyVer').

Audit/WORM - immutable store of money/rounds/payments events.

Reporting - export by jurisdictions (MGA/UKGC), SLA for completeness/timeliness.

Sample streams

Rate → calculation → payment

1. 'gaming-bridge' sends' bet. placed` (idempotent).

2. 'wallet' makes' hold'and publishes' wallet. hold`.

3. 'gaming-bridge' gets the result of the → 'round provider. settled`.

4. 'wallet' considers' settle '(release/payout) →' wallet. settled`.

5. 'promo' consumes events and accrues a bonus → 'bonus. issued`.

Cash desk (deposit)

1. 'cashier' creates a 'payment. intent` с `Idempotency-Key`.

2. PSP calls webhook → 'cashier. webhook. received`.

3. `wallet. credit 'actually → an event for analytics and RG.

Changes without downtime (expand→migrate→contract)

1. Expand: Added fields/endpoints to 'v1. 1 ', old customers don't break.

2. Migrate: consumers read new things, write in both versions (dual-write only for non-monetary).

3. Contract: announced EOL 'v1. 0 ', removed after N weeks as planned.

Platform engineering

Golden Paths: module templates (repo askeleon, CI/CD, alerts, SLO, secrets).

Contract tests: Pact/AsyncAPI tests in CI; integration environment with fake providers.

Service catalog (Backstage): who is the owner, SLA, API versions, incident books.

Modularity Success Metrics

Lead time from idea to production release ↓ X times.

Release frequency by ↑ module (per day/week), change-fail rate ↓.

MTTR on ↓ incidents (due to isolation).

Infra cost/GGR is stable or ↓ with traffic growth (selective scale).

Provider/PSP integration time (from briefing to prod) ↓.

Anti-patterns

Microservices for Microservices. Without clear data boundaries, connectivity and complexity are growing.

Common DBs/diagrams between modules. Kills isolation and independent releases.

Events without version/contract. Break consumers "quietly."

Dual-write for money. The risk of inconsistency is only idempotent steps through one writer.

Global "utility layer" with everything. Turns into a hidden monolith.

No feature flags and kill-switch. Any mistake immediately hits everyone.

OLTP/OLAP mix. Reports slow down rates/wallet.

No observability. There is nothing to measure SLO and link incidents.

Modular Architecture Transition Checklist

Strategy and domains

Bounded contexts, owners, and module KPIs are defined.
Interaction map: API/events, criticality and SLO.

Contracts and security

OpenAPI/AsyncAPI + JSON-Schema; version and life cycle.
mTLS/HMAC, short JWT, RBAC/ABAC at borders.

Data

Split OLTP; events are the source for OLAP.
Idempotency on API/webhooks, message deduplication.

CI/CD & Releases

Canary/blue-green, feature flags, autoscale modulo.
Contract tests in CI; environment with fake providers.

Observability

Logs/metrics/trails with 'traceId'; SLO dashboards.
Alerts by business metrics (VOID, reject, payout lag).

Compliance

WORM archive of money/rounds, export of regulatory reporting.
KYC/AML/RG as a separate module with a solution log.

Mini-examples

Event'round. settled@v1`:

json
{
"event":"round. settled",  "v":"1",  "roundId":"R-2025-10-17-evo-23",  "gameId":"evo_blackjack_23",  "bets":[{"betId":"b_92f","playerId":"p_1","stake":"10. 00","payout":"15. 00","outcome":"WIN"}],  "ts":"2025-10-17T14:23:13. 120Z",  "traceId":"tr_5f1"
}

Idempotent wallet:

http
POST /wallet/settle
X-Idempotency-Key: 9a7f-2b1c
{
"roundId":"R-2025-10-17-evo-23",  "operations":[{"playerId":"p_1","delta":"5. 00","currency":"EUR"}]
}

The modular architecture turns the casino platform from a "fragile combine" into a composition of reliable domains: each with its own contracts, data and SLO. This speeds up integrations and releases, provides selective scaling, simplifies compliance, and reduces incident risks. Start by highlighting domain boundaries, contracts and events, weave in security and observability - and you get a platform that grows with the product, not slows it down.