An enterprise iGaming operator's hardest day is not launch day. It is the Tuesday in year three when one brand's bonus engine bug starts double-crediting accounts at 30k concurrent users, the SRE team is paged at 2am, and the on-call engineer has 14 services to triage across four regions. The platforms that survive these days are the ones designed for them — not the ones that scaled a startup codebase past its architectural limit. Sudonex builds enterprise iGaming platforms where multi-brand, multi-region, and high concurrency are first-class assumptions.
What enterprise means here
Enterprise is not a synonym for expensive. It is a set of operating constraints: 5 or more brands under one platform, 2 or more regulatory regions, 50k+ daily active players per region with seasonal spikes to 100k+ concurrent, regulatory reporting in 5+ jurisdictions, B2B partnerships requiring isolated tenant data, and a release cadence that ships to production daily without coordinating across product teams. A platform that meets those constraints looks fundamentally different from a single-brand operator stack.
Multi-brand, multi-region
Multi-brand is shared platform, isolated tenant. Each brand runs in its own logical tenant — separate database schema, separate domain, separate front end, separate bonus rules, separate license attribution — but shares the platform code, deployment pipeline, and operations team. Multi-region is geographic data residency plus latency. We deploy active-active across at least two regions per geographic market, with player data resident where the regulator requires (UK data in UK, German data in Germany under LUGAS). Inter-region replication is asynchronous for most data and synchronous for the wallet ledger.
Microservice architecture
The enterprise stack is built around 20-plus services: identity, KYC, wallet, ledger, payments, bonus engine, games proxy per provider category, sportsbook, exchange, CRM, notifications, fraud, AML, regulatory reporting, and so on. Services communicate over a service mesh (Istio or Linkerd) with mTLS, and via an event bus (Kafka) for asynchronous flows. Each service has its own database, its own deployment pipeline, and its own on-call rotation. A bonus engine deployment does not touch the wallet binary.
The non-negotiable architectural rules: the wallet is the source of truth for balances and is never bypassed; every player-facing action is idempotent and traceable to a request ID; every service exposes a /health and /metrics endpoint; cross-service calls have circuit breakers and bulkheads; nothing reads or writes another service's database directly.
Observability
Four pillars: metrics (Prometheus), logs (Loki or Elasticsearch), traces (OpenTelemetry to Tempo or Jaeger), and synthetic checks. Every player journey — registration, deposit, bet, withdrawal — has a synthetic that runs every minute per region. SLOs are published per service and tracked against an error budget. When the error budget for the wallet burns 10% in a day, deploys to the wallet stop until burn rate recovers. This is the discipline that keeps the Tuesday-2am call from happening every Tuesday.
Scaling to 100k+ concurrent
Three levers. First, statelessness — every service except the wallet ledger and the games session store is horizontally scalable behind a load balancer. Second, caching — Redis clusters in front of player profiles, game catalogs, and bonus eligibility, with cache invalidation tied to event bus messages. Third, sharding — the wallet ledger is sharded by player ID, with cross-shard transactions reserved for B2B partner settlements that run async.
Services and modules
Enterprise builds typically integrate the full Sudonex catalog: casino app development and igaming UI/UX design for the player surface, sports exchange development for peer-to-peer markets, igaming API integration for the dozens of provider connections an enterprise platform requires, security audit and penetration testing on a quarterly cadence, and igaming maintenance and debugging as a 24/7 service offering.
Use cases
Tier 1 operators consolidating a portfolio of acquired brands onto one platform, B2B platform vendors selling to 10+ operator clients, listed gaming groups whose audit requirements exceed what their legacy stack supports, and US operators expanding across 8+ states where regulatory granularity demands per-state configuration without per-state codebases.
FAQ
What does an enterprise build cost
Builds start around 3M USD and scale with brand and region count. The economics work above roughly 50M USD GGR per year — below that, an upgraded white label is usually a better answer.
Do you migrate from a legacy platform or build greenfield
Both. Migrations are the harder path: we run the new platform in parallel, migrate brand by brand, and decommission the legacy stack over 6 to 18 months.
How do you handle a games provider outage
The games proxy isolates each provider. An outage at one provider returns errors only for that provider's titles; the rest of the catalog stays live. Players see provider-specific error messaging.
What are the SLA targets
- 99% platform availability per region, sub-200ms p99 wallet response, sub-1s p99 bet placement. These are baked into the architecture, not promised on a slide.
Who operates the platform after launch
Options are: Sudonex managed (SRE retainer), customer operated (we transition with a 6-month handover), or hybrid (customer ops, Sudonex on call for severity 1).
Scope an enterprise build
Contact Sudonex with your brand portfolio, region map, and current platform pain points. We will return a phased architecture proposal and migration plan within 10 business days.