Microservices in iGaming: Designing for Uptime During Peak Traffic

Last updated: 2026-07-31 • Author: Senior Platform Architect • Tech reviewed by ex‑SRE

19:58 UTC. Two minutes to kickoff. Odds spike. Wallet writes climb. Bet requests jump from 3k to 45k RPS in under 90 seconds. A noisy alert fires for timeouts on the bet path. Another alert says “risk model slow.” A third alert shouts “queue depth high.” Half the team stares at traces. The other half checks the ledger.

Here is what saved us: strong limits on the hot path, fast circuit breaks on slow feeds, and a “peak-mode” switch that dimmed promos in 15 seconds. Here is what hurt: retries without budgets, one shared cache for too many services, and a missing idempotency check on a legacy route. Also, note this: DDoS-like spikes are not always bots. Real users can stampede, as the Cloudflare blog shows with real traffic stories and fixes.

What “peak” really means in iGaming

Peak is not just “more traffic.” It is bursty. It is uneven across services. It is tied to live events and promos. Sports start times are easy to plan. But other spikes come fast and hard. A star posts a promo link. A same‑game parlay goes viral. A wallet bonus drops at half‑time. KYC checks pile up when a push offer lands. Geo checks surge when fans travel.

So we model peaks by path. The “hot” path is bet write, wallet, odds. The “warm” path is account, KYC, promos. The “cold” path is BI and CRM. We set clear goals per path. We use SLOs, not just SLAs. The Google SRE workbook has a plain guide on SLOs, error budgets, and how to tie them to user impact.

A snapshot you can run: thin edge, fat core

Keep the edge light (CDN, WAF, API gateway). Keep the core strong (queues, state, storage). Split reads and writes. Do not let the odds firehose slow the bet writer. Send bet writes to a queue right away, then to the ledger. Keep risk checks in line but lean. Move rich pricing and content to async where you can.

For patterns you can copy, the AWS Well‑Architected reliability pillar is a good base. For service isolation ideas and real case studies, the CNCF site has many cloud‑native examples you can adapt.

Boundaries that do not bite at 20:00

Make every write on the bet path idempotent. Use an Idempotency-Key. Store it with the result. If a client retries, you return the same answer. Stripe has a clear, short guide on this: idempotency keys.

For wallet + bet atomicity, pick a simple, proven path. Outbox + transaction logs are easy to run. Sagas can work but add many steps. When traffic is hot, fewer hops win. See the trade‑offs in Martin Fowler’s piece on the Saga pattern.

Uptime is a policy: SLOs, burn rates, and peak mode

Write SLOs per path. Example: bet write p99 < 120 ms, odds fan‑out p99 < 200 ms, wallet balance read p99 < 80 ms. Tie alerts to burn rates, not single spikes. Multi‑window alerts cut noise and catch real pain. The Google SRE guide on alerting shows how to set fast and slow windows for this.

Define “peak mode.” It is a switch, not a hope. In peak mode, you can dim promos, pause heavy recompute, serve stale odds for up to 5 s, and lift fair‑queue limits per user. Think of it as a safe, short‑term plan you can turn on in one minute.

Brown out promos and heavy banners
Set odds TTL to 5 s for UI reads
Raise queue size on bet-writer by 2x
Drop verbose logs; keep error and trace head samples
Freeze risk model to last safe weights for 2 min
Turn on fair-queue per user and per IP

Capacity playbook: headroom, autoscaling, safe shedding

Keep headroom for live events. 30–50% spare for the hot path is normal for big nights. Autoscale on the right signal. CPU is not enough. Use queue lag, request rate, and p99 latency. The Kubernetes HPA docs show how to use custom metrics and safe cooldowns.

When you must shed load, do it fair and clear. First, soft limits per user. Then per IP. Then per region if a data center is hot. Shield the hot path with a queue. This is classic “queue‑based load leveling,” well shown in the Google Cloud Architecture Center. Always log who you shed and why. Give a simple, honest message to the user.

Data truth: events, cache, and failovers

Use Kafka (or a peer) for events and back‑pressure. If you need “exactly once,” be careful and test. The Confluent blog on exactly‑once explains the limits in plain words. For hot tokens and quick reads, use Redis, but plan the cluster and slots with care; see the Redis scaling docs.

For balances and bets, you want strong truth. Postgres with Citus for sharding, or a NewSQL store, can work. Start with one region + sync replicas. Drill failover steps. The Citus docs show how to shard and keep transactions sane. Use circuit breakers on writes. If you must dual‑write, set a short window to reconcile, and track drift.

Observability for the 90th minute

Use RED (Rate, Errors, Duration) for services and USE (Utilization, Saturation, Errors) for infra. Traces tie it all. Mark the hot path spans. Sample smart, not all. Add labels you really need: market, sport, region, bet type. Avoid high‑card keys like user agent strings. OpenTelemetry makes this set up clean; start with the OpenTelemetry docs.

Give each team a small runbook. One “golden” dashboard per hot service. Alerts that wake you must be tied to a user pain and to a fix you can do fast. No more “CPU high” pings at 3 a.m. unless it means “bets fail now.”

Incident diary: a 12‑minute brownout

At 20:11 UTC, odds refresh slowed from 150 ms to 1.2 s. The feed fan‑out held CPU. Wallet writes went fine, but the bet writer hit its retry cap due to slow risk checks. Timeouts stacked. Queue depth rose to 18k. We turned on peak mode at +3 min. We cut promos. We raised queue size. We served stale odds (5 s). We halved risk weight updates.

At +8 min, bet path p99 fell under 100 ms. At +12 min, odds back to 220 ms. Root cause: a hot league feed sent 10x ticks due to a mis‑tag. What helped: queues, circuit breaks, idempotency. What hurt: one shared Redis for odds and promos, and missing fair‑queue per user on the bet route.

iGaming is not “just e‑commerce with bets”

We face rules that change uptime plans. Geofence must work. AML checks must run. Logs must stay. Some things you can dim. Some you cannot. The UK sets strict remote tech rules. See the UK Gambling Commission remote technical standards for a sense of the bar.

Also note traffic sources. Peaks do not come only from game time. They also come from partners and publishers. Large affiliate posts can send a fast “micro‑burst” of real users in minutes. When a trusted portal shares a timed page of new online casino reviews during a live match break, you may see 10–15x new sessions over an 8–12 minute span. Plan for that shape: many new users, more KYC checks, more geo checks, and more wallet opens than usual.

Build vs. buy: edge and core

Buy guard rails at the edge (CDN, WAF, bot rules) if you can. Keep core risk and wallet close. Use Envoy for safe limits and breaks; see Envoy circuit breaking for sane defaults. Do not let a vendor own your hot path keys (idempotency, bet log, wallet truth). Test vendor limits with chaos runs in a safe lab. A short intro to this is here: Principles of Chaos Engineering.

Avoid lock‑in on events. Use open formats. Keep a clear exit plan from any feed or queue vendor. Make this part of your risk list.

The hot‑path readiness table

Paste this into your runbook. Adjust numbers after load tests and real nights. Keep it short and alive.

Bet Writer	p99 write > 60 ms OR queue lag > 1k msgs OR CPU > 70%	min 8, max 60; step +30%; cooldown 60 s	client 800 ms; server 300 ms; 1 retry with Idempotency‑Key	Open at 20% 5xx/timeout over 30 s; half‑open probe 5 rps	Queue to Kafka, return “processing”; brown out promos	Postgres+Citus; outbox to Kafka; strong write order	RPO 0; RTO 60 s
Wallet	p99 txn > 80 ms OR DB write stall > 100 ms	min 10, max 80; step +25%; cooldown 45 s	client 1 s; server 250 ms; 1 retry idempotent	Open at 10% timeouts/60 s; half‑open 3 req per shard	Queue writes; read from leader only; freeze bonus calc	Postgres/Cockroach; serializable for balance	RPO 0; RTO 60–90 s
Odds Feed Aggregator	feed lag > 200 ms OR event loop backlog > 5%	min 6, max 40; step +50%; cooldown 30 s	socket 150 ms; no retry on price; use last known	Trip on 3 slow ticks from a source; isolate that feed	Serve stale odds up to 5 s; mark “updating”	Redis for cache; Kafka for fan‑out; TTL 2–5 s	RPO n/a; RTO 30 s
Risk / Limits	p99 model > 50 ms OR queue > 500	min 6, max 40; step +25%; cooldown 45 s	budget 120 ms; no retries; backpressure to bet writer	Trip at 5% slow calls; fall back to coarse limits	Use static caps for 2 min; log every coarse decision	Feature store + Redis; write audit to Kafka	RPO n/a; RTO 60 s
Geolocation	p95 > 70 ms OR third‑party lag > 150 ms	min 4, max 20; step +50%; cooldown 60 s	timeout 100 ms; no retries; ask user to retry	Trip on 2 timeouts in row per IP	No bet if geo fails; cache pass for 3 min	Local DB + vendor; cache by IP/device	RPO n/a; RTO 30 s
KYC	queue > 200 OR p95 > 300 ms	min 2, max 20; step +100%; cooldown 120 s	timeout 1.5 s; 1 retry async	Trip at 10% vendor errors; route to alt vendor	Queue and notify; no block on bet settle	Kafka + vendor; audit log write‑ahead	RPO < 1 event; RTO 5 min
Notification / Receipt	event lag > 500 ms OR DLQ growth > 50/min	min 2, max 30; step +50%; cooldown 45 s	timeout 1 s; 2 retries with backoff	Trip on 15% failure; pause push; keep in app inbox	Show receipt on site; send push later	Kafka + email/SMS; idempotent send keys	RPO < 1 event; RTO 10 min

Small but key details

Keep retries under a budget. A good start: retry ≤ 1, backoff ≤ 200 ms, total time ≤ user SLO.
Use fair‑queue. One user should not starve others. It helps a lot when many bots try at once.
Keep hot caches small and fast. One cache per concern. Do not put odds and promos in the same Redis.
Set clear timeouts between services. A slow peer should not slow the whole mesh.

Two short snippets you can paste

Envoy circuit breaker (simple)

HTTP client retry budget

A quick bit of math for capacity

Say your bet writer p99 is 60 ms at 1k RPS per pod. You project 30k RPS peak with a 1.5x safety headroom. Needed steady RPS: 45k. Pods for steady: 45 pods. Add 20% for noise and slow warmups: 9 pods. Round up and set min=54 pods before kickoff. Let HPA go to 60 if queue lag rises. Keep cooldown at 60 s to avoid flaps.

FAQ

TL;DR

Model peaks by path: hot (bets, wallet, odds), warm (KYC, promos), cold (BI).
Use idempotency keys and a queue first on the bet path.
Set SLOs and burn‑rate alerts; have a one‑click peak‑mode.
Autoscale on queue lag and p99, not just CPU; keep 30–50% headroom.
Serve stale odds for 5 s if needed; never risk wallet truth.
Isolate by network, queue, and data store; avoid shared hot caches.
Practice failovers and traffic bursts before game night.

Change log: 2026‑07 — added burn‑rate alert example and readiness table thresholds.