Disaster Recovery and Multi-Region Failover for iGaming

It is derby night. Live bets spike. Your main region is hot. Then a write spike hits the wallet DB. Latency jumps. Cash-out hangs. Some slips time out. Support chat fills up. Your team flips to plan B. DNS starts to move traffic. But the standby is cold on promos, and one queue lags. You face refunds, bonus abuse, and a long night. This guide shows how to build a plan you can trust on days like this. By the end, you can sketch a DR and failover path that keeps bets safe, players calm, and regulators off your back.

What “recovery” means here, not in a slide

Two goals rule the room: time to get back up (RTO) and data you can afford to lose (RPO). In iGaming, these touch money, odds, bet slips, jackpots, and promo states. A clean page view is nice, but wallet integrity wins. Your RPO for wallets should be near zero. For bet slip state, seconds. For non-core data like logs or BI, minutes can be fine.

Do not mix these with your SLOs. An SLO is what players feel (p95 latency, success rate). RTO/RPO are for the moment things break. Write them per domain: wallet, bet engine, KYC, payments, promos, content. Price the gap. Every minute of outage can cost revenue, churn, and fines. If bet history is not the same across regions, you face disputes and a loss of trust. For a shared frame on terms, see the NIST contingency planning guidance.

Your menu of patterns (and what they really cost)

Pick a pattern per domain, not one size for all. Common paths are pilot-light, warm standby, active-passive, active-active, and some hybrids. Each has a price in cash and in ops work. In iGaming, the hard part is not CPUs. It is state. A promo counter here, a wallet ledger there, a bonus wallet in a side store, and a bet stream on Kafka. The wrong mix can cause drift. Drift becomes loss.

As you weigh choices, map target RTO/RPO to the wallet and bet engine first. Use caches to smooth reads. Use queues to buffer spikes. Use strict write paths for money. The AWS Well-Architected Reliability Pillar gives a clean check-list of trade-offs. If you are on Microsoft, look at Azure paired regions design for built-in cross-region options.

Steer traffic without rolling dice

Global traffic tools can save you or sink you. DNS-based GSLB is simple and fast to set up. Health checks tell it where to send users. But TTLs lie during a hot failover. Some ISPs pin answers. Use short TTL and stale-if-error on caches. Anycast with BGP is fast but needs network skill. Provider-native traffic managers add region checks and stickiness. See Cloudflare load balancing and health checks for a clear model.

For deep geo control, you can also look at Akamai Global Traffic Management. No matter the tool, plan for brownouts, not just blackouts. Fail back is a plan too. Make it a runbook step, with guard rails and a go/no-go gate.

The hard bit: keeping wallet and bet data correct

Most pain sits here. A bet is a set of writes: take stake, lock odds, store slip, send to engine, settle, credit wins, update bonus, move tags for AML. Across regions, strong consistency is hard. Latency kills lock-based writes. If you go multi-writer, you risk double credit. If you go single-writer, you need fast, safe replicas and clear cutover.

One pattern that works well: single-writer per domain, logical replication to other regions, and idempotent writes on all money flows. This keeps RPO near zero and RTO in minutes. Read replicas in each region serve reads. A message outbox ties events to commits. On failover, a reconcile job sweeps for gaps. If you use Postgres, read the docs on PostgreSQL logical replication as a base.

Some stacks prefer MySQL. Group Replication gives you a base for failover, but test write conflicts with care. See MySQL Group Replication. In all cases: use idempotency keys on payments, dedupe on queues, and a clear ledger for wallet moves that you can replay and prove.

Events and streams when regions fall over

Event streams help absorb spikes and let you replay. Many use Kafka for odds, slips, and settlements. Cross-region brings lag and ordering issues. Exactly-once is a promise with footnotes. Use it with care. Split topics by region. Make consumers able to reprocess messages. Store offsets in a way you can move with a cutover plan.

For deep dives, this post on Multi-region Kafka design is a strong start. Build a test to replay one hour of peak traffic into the standby region. Check that all balances, slips, and AML flags match at the end.

Secrets, keys, and the DR you hope you never try

Do not forget your vault. Replicate secrets, tokens, and keys across regions. Avoid split brain for KMS roots. Protect HSMs. Back up OIDC and SAML configs. Rotate on failover if a key scope changes. Keep a sealed copy of env files with legal hold rules.

If you run HashiCorp Vault, read up on Vault DR replication. Practice an unseal in the dark. Time it. Log it. Store the proof.

Regulators do not care about cluster state

They care about player funds, data location, and audit trails. Show where data sits. Prove who touched what and when. Wallet ledgers must match. KYC and AML logs must be intact. Payment flows must keep to PCI scope. Keep evidence packs: drill logs, configs, access lists, and change records.

Review the PCI DSS overview to frame card data scope. For wider EU guidance, check ENISA good practices on resilience. Map which data sets must stay in-region. If the law is gray, ask counsel. Document the call.

Prove it works: game-days, chaos, and SLOs

We ran a game-day once. At minute 7, a read cache masked a dead write path. Our play bets “worked,” but the wallet did not move. We stopped, fixed the health checks, and changed the SLO to include write success. Run safe chaos: kill a region, break DNS, freeze the primary DB, add packet loss. See core ideas in Chaos engineering principles.

Write SLOs by domain: wallet p99 write, slip create, settle time, KYC pass. Tie error budgets to promo burn and payment fails. Rehearse cutover in work hours first. Use the SRE workbook on SLOs/error budgets to shape tests that have clear pass/fail gates.

Runbooks win nights. Keep a short list for who calls whom, who has the DNS key, and what to post where. Have pre-written posts for status pages, partners, and a first note to the regulator. See sample Incident response runbooks and adapt them to your org chart.

Costs: count the chips, not just servers

Active-active is not “double the cost.” You may right-size each region and use spillover at peak. Your big costs are egress, storage, cross-region writes, and warm capacity. Drill time is time well spent, but it is a line item too. Track people time in your model.

Use FinOps to make this clear to the board. Tag all DR parts. Show unit cost per 1,000 bets at peak and off-peak. Turn off what does not need to be warm. See the FinOps Framework for a common language with finance.

Talk to players, partners, and the house

A calm, clear note beats silence. Use a public status page. Share a plain summary first: what broke, what is safe, what is next, and when. Do not hide times. Tell users if they must do anything. Keep updates on a schedule. After fix, post a short, human RCA.

Tell your partners fast. That means PSPs, KYC, content feeds, and key affiliates. Include review sites in your contact list so facts spread, not rumors. For example, we keep an email group for top partners and a live sheet. A trusted review portal that covers tables and streams, like Live Dealer Spiele online, should be on that list. They can post clear notes to players and cut ticket load for you.

30/60/90 days to sleep at night

Day 0–30:

• List domains: wallet, bets, promos, KYC, PSP, content, BI.
• Set target RTO/RPO per domain (wallet: RPO ≤ 60s, RTO ≤ 10m; bets: RPO ≤ 30s; promos: RPO ≤ 5m).
• Pick patterns per domain (e.g., wallet active-passive; content warm standby).
• Draft runbooks for failover, failback, and reconcile. Assign names and keys.

Day 31–60:

• Set up traffic manager with health checks and short TTL.
• Enable DB logical replication and read replicas per region.
• Add idempotency keys to payments and bet writes. Wire the outbox pattern.
• Stand up a game-day test plan. Add synthetic flows. See this Synthetic monitoring guide for ideas.

Day 61–90:

• Run your first failover drill in work hours. Record all times and gaps.
• Fix the slow steps. Patch health checks. Tune caches.
• Build the evidence pack for auditors: logs, times, configs, approvals.

FAQ

How do we reconcile unsettled bets after a failover?
Keep a ledger of state moves. Mark every bet with an idempotency key. On cutover, stop writes for a short, known window. Replay from the outbox to the new writer. Run a reconcile job that checks wallet deltas, bet states, and promo burns. Flag any gap for manual review.

What is the minimum to pass a regulator readiness check?
Show a clear RTO/RPO per domain, proof of a drill in the last 6 months, audit trails for access and change, data location maps, PCI scope for payments, and a contact tree. Have one game-day log with times and results. Have a status page plan and a draft incident note.

How often should we run game-days?
At least quarterly. Before known peaks, run a short drill (30–60 min). After any big change in infra, run a targeted drill (DB, DNS, PSP fail, or cache loss). Rotate who leads. Keep the same pass/fail bars, so you can track trend over time.

A short story from the field

We once failed over a live sportsbook in under four minutes. Players did not notice. But the promo counter was stale by 11 minutes, so a small group got double spins. Fix: we moved promo writes to the same ledger pattern as wallets, added an outbox, and wrote a reconcile job that can claw back only the extra promo amount with a soft rule set. That change paid for itself on the next event night.

Checklist you can copy today

• RTO/RPO per domain, on one page.
• Traffic manager set with per-region health checks.
• Single-writer for money. Logical replicas in other regions.
• Idempotency keys for payments and bets.
• Outbox pattern for events tied to DB commits.
• Kafka topics split by region; replay test data weekly.
• Vault DR tested; unseal and key ops timed and logged.
• Status page templates and regulator notes ready.
• Quarterly game-day booked, with pass/fail gates.

Quiet next step

Want a second set of eyes on your DR map? Send your domain list and RTO/RPO targets. I will share a one-page pattern pick, a drill script, and a reconcile checklist you can run this week.

Author

Alex M., iGaming platform engineer, 10+ years in EU and LatAm markets. Led 30+ game-days, PCI scope owner, ex-SRE lead for a tier-1 sportsbook. Last drill cut wallet RPO from 5 minutes to 30 seconds with logical replication and an outbox.