Why iGaming is switching to microservices

Full article

💡 18+. The material is educational. Not a call to play. The focus is on the engineering reasons for the change of architecture.

1) Context: why the monolith stopped working

iGaming is growing in content, geography and regulation. Monolithic codebase:

slows down releases (general depla windows, the risk of regressions), scales poorly (wallet and cash desk are hot, and CMS is cold), interferes with compliance (different regulators → different data rules), complicates the isolation of money (money-flows and bonuses are intertwined).

The result is high incident risks and a slow time-to-market.

2) What gives a microservice approach

1. Isolation of critical domains. Wallet/Ledger, Cashier/PSP, Bonus Engine, Game Sessions, KYC/AML, RG, Risk/Fraud, Affiliates, CRM - separate services with their own SLOs.

2. Scaling by consumption. Hot services (wallet, cash register, game session) get more resources without inflating the entire cluster.

3. Independent releases. Commands deplete according to their cycle (canary releases, feature flags).

4. Fault tolerance. Local degradation does not bring down the entire product (cashier degrades - games continue due to caches and queues).

5. Legal segmentation. PII and payment spread by region (EU/UK/BR) and date residence.

6. Flexibility of integrations. Parallel connection of game providers, PSP and KYC providers.

3) Basic scheme (simplified)

Edge layer: API Gateway, WAF/bot protection, rate limiting, geo filters.

Domain microservices: Wallet/Ledger, Bonus, Cashier, Game Gateway, Risk/Fraud, RG, KYC/AML, Affiliates, CRM, CMS, Reporting/Compliance.

Event bus: Kafka/Pulsar - 'bet. placed`, `bet. settled`, `wallet. debit/credit`, `cashier. deposit. succeeded`, `rg. limit. hit`, `bonus. consumed ', etc.

Data: OLTP database for service, outbox/CDC → DWH (ClickHouse/BigQuery).

Observability: metrics/logs/trails; SIEM/SOAR; audit-log WORM.

4) Money and integrity: Why it's key to migration

The main argument "for" microservices is the rigid isolation of the monetary circuit:

separate Ledger with strict ACID and command idempotency, sagas for long processes (deposits, cashout, bonus accruals), outbox + transactional event publishing, zero tolerance for "manual edits" of balances.

This design reduces the probability of loss/duplication of settlements to zero at the architectural level.

5) Patterns without which microservices won't take off

CQRS + projections. Commands - strictly through domain APIs; reading - through projection models.

Idempotency Keys. Each money/bonus team is repeatable with no side effects.

Sagas and compensations. Explicit compensating events instead of "DB rollback."

Schema Registry. Event Contract Versioning producer/consumer compatibility.

Rate limits/Retry/Backoff. Network failures are the norm; customer stability.

Zero-trust and secrets. mTLS inside mesh, Vault/HSM, minimal privileges.

6) What's Harder About Microservices (Honest About The Cons)

The network is more expensive than memory. More RPC, increased latency and cost of infrastructure.

Data complexity. Consistency - eventual beyond Ledgera, projections needed.

Observability. Without end-to-end tracing and SLO, everything quickly turns into a black box.

Team discipline. Contract tests, release rituals, scheme migrations are required.

Cross-regional gaps. Data residency requires thoughtful shardization.

If the company is not ready for DevOps/SRE culture, a monolith "with good modularity" may be better.

7) Step-by-step migration: from monolith to services

Step 1. Standardize events. Enter the tire and a single dictionary: player, bet, settlement, deposit, bonus.

Step 2. Take out the Ledger. The money circuit is separated first: a separate database, command API, outbox.

Step 3. Separate Cashier. PSP orchestration, cascades, 3-DS, reconciliations - as an independent service.

Step 4. Game Gateway. A single gateway to game providers; sessions/collbecks - not through a monolith.

Step 5. Bonus Engine и RG. Rules, vager, limits - offline, subscription to wallet/game events.

Step 6. Risk/AML + KYC. A separate circuit with its own integrations and alerts.

Step 7. Data and BI. CDC in DWH, KPI showcases, anti-Excel reporting.

Step 8. Back-office. RBAC/ABAC, audit log, "4 eyes" for Crete action.

In parallel - canary releases, phicheflags, rollback, regular DR exercises.

8) Operating experience: which SLOs are considered the norm

Kernel uptime (wallet/cashier/game-gateway) ≥ 99.95%.

p95 wallet latency <150 ms; cashier authorization <3 s.

"Lost/Duplicated Settlements" = 0.

Delivery of events to BI-showcases ≤ 5 min.

MTTR for core incidents <30 min.

9) Security and compliance "by default"

PII/payment data segmentation, PCI DSS, GDPR/local analogues.

At-rest/in-transit encryption, short-lived tokens, key rotation.

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

Audit logs in WORM storage, access according to the principle of least rights.

10) Economics and organizational effects

TTR releases ↓: Independent dispatches reduce task queues and context switch.

Cost-to-scale ↓/↑: horizontal scaling is much cheaper, but you need a well-thought-out FinOps (autoscale, limits, spot instances).

The risk of incidents is ↓: blast radius is limited to the service.

Product speed ↑: new providers/PSPs and features do not expect a "common window."

11) Microservice iGaming core maturity checklist

Ledger - a separate service and database, only command API, outbox/CDC.
All cash/bonus transactions are idempotent, deduplication keys are everywhere.
Event bus with circuit register; backward-compatible contracts.
Cashier with PSP cascade and daily sparkles.
Game Gateway with "no new sessions" degradation in incidents.
RG/AML - synchronous stop signals on the bet, reality-checks.
Observability: metrics/logs/trails on end-to-end trace_id; dashboards SLO.
DR-plan: RPO ≤ 5 min, RTO ≤ 30 min; regular exercises.
Data residency and PII masking; RBAC/ABAC and "4 eyes."
BI without manual Excel: KPI showcases, cohorts, LTV, reports to regulators.

12) Red Flags (Antipatterns)

Manual edits of balances/bonuses in the database.

A single database "for everything," BI hits battle tables.

Publishing events "bypassing" domain transactions (no outbox).

Lack of event schema versioning.

Zero idempotence and retrai "as it turns out."

Payment failures without cascade and detailed telemetry.

No RG/AML stop lights on critical paths.

Microservices in iGaming are not a tribute to fashion, but a way to spread money, risk and product along independent contours, speed up releases and reduce the scale of incidents. The key is monetary integrity (Ledger + idempotency + sagas), eventfulness (tire + contracts) and SRE/DevOps culture. With this foundation, the platform can withstand the growth of traffic, geographies and regulatory requirements, while remaining fast, transparent and secure.