The SOFTSWISS stability playbook on how to protect operator GGR

EGR: People often quote ‘uptime’ and stop there. Beyond uptime percentages, what does ‘stability’ actually mean for the SOFTSWISS Casino Platform?

Denis Romanovskiy (DR): Uptime is just the tip of the iceberg. Behind our 99.999% uptime commitment lies an ecosystem of processes; we monitor the performance of individual components, not just the platform as a whole. For example, the cashier – the part of the platform that handles deposits and withdrawals – has its own service level objective (SLO) of 99.99% availability, because a global status that says ‘all systems operational’ is meaningless if players can’t deposit. We also track latency with service level indicators (SLIs), such as the share of cashier requests served in under 300ms, so we know it’s not just up, it’s fast enough. 

On top of that, we watch error-budget burn rate – how quickly we consume the allowed risk – and deployment stability, the percentage of releases that don’t trigger incidents or rollbacks. 

If we only looked at uptime KPIs, we might think everything was fine while players were stuck on loading screens. Only when taken together do these indicators show whether we’re stable, fast, and safe to change. 

EGR: How do those engineering SLIs translate into player and revenue impact?

DR: We track player experience metrics that move in step with business outcomes. A few examples: if the average number of sessions per user suddenly drops or the share of error-free game sessions dips, it’s a clear signal that something’s off. The same applies to payments – even a one- or two-point drop in a successful deposit/withdrawal rate has a direct impact on GGR.

On the UI side, we monitor core web vitals, such as LCP (largest contentful paint) that defines how quickly the largest visible content loads, or FID (first input delay) the time between a player’s first tap or click and the browser’s response. If average LCP drifts above four to eight seconds (depending on connection type) or FID becomes unstable, new players are far more likely to bounce.

We also track new-player churn and retention rate. Spikes or dips often correlate with latency or error patterns. When these metrics show negative trends, we analyse the tech signals behind them. 

EGR: Stability is tested when traffic spikes. How do you prepare and scale without disrupting gameplay flow?

DR: There are two scenarios why traffic jumps: planned and unexpected.

For planned surges, we work with the operator to forecast demand and pre-scale – typically within about two weeks, though we can move faster if urgent. Scaling can go vertical or horizontal and, depending on the scope, we can do it either with zero downtime, or with a short maintenance window, or, in case of major infrastructure shifts, up to about an hour. As a baseline commitment, we have provision for 3x the monthly average traffic without performance loss. Beyond that, we just ask operators for prior notice so we can reserve extra capacity.

For unexpected spikes, like viral jackpots, aggressive promos or even DDoS, we design the system to handle five to 10 times the average traffic load. We keep a warm reserve – extra capacity that stays partially active and can be scaled up quickly – and our site reliability engineers (SREs) to monitor live dashboards. When a promotion campaign takes off faster than the dedicated resources can handle, we add extra capacity immediately. We’ve had several cases where the jackpot counter hit the threshold, and traffic tripled within minutes. Thanks to our strategy of building abundant capacity, we kept SLI latency within normal limits and consistently met our guaranteed SLOs.

EGR: How does the SOFTSWISS Casino Platform maintain consistent performance across geographies?

DR: Architecture and routing matter more than raw compute capacity. We run a hybrid infrastructure across clouds and data centres and push content to a global edge, making sure players connect to the closest point of presence. It’s especially important for the Latam and Africa markets, where internet connections are often less stable.

We keep an eye on a few simple ‘speed dials’. One is Time to First Byte (TTFB) – basically how fast the server starts responding – and we aim for 0.8 seconds or less. I’ve already mentioned LCP, where four to eight seconds or less is our sweet spot. We also watch Time to Interactive (TTI) for particular website functions like registration, login and deposit, which is when the page is fully usable and responds to input – three to six seconds (depending on connection type) is ‘green’ for us. 

To keep those numbers within range, we combine synthetic tests with real-user monitoring. Then we tune server-side rendering, image optimisation and edge computing in each region to ensure pages load quickly even on weak connections.

EGR: If something does go wrong, how do you contain the impact and recover fast?

DR: Nothing is fully error-proof. That’s why we design for bad days. Architecturally, this means building in redundancy at every layer: multiple-node app tiers behind load balancers, queues and delayed processing for spikes, rate limiting and circuit breakers on external calls, plus graceful degradation when a dependency misbehaves.

Security-wise, we lean on providers like Cloudflare and others for DDoS protection, hide origin servers and enforce rate limits so brute-force or bot floods don’t drown relevant traffic.

Operationally, we run 24/7 monitoring via services like Zabbix, Site24x7, Datadog and Prometheus to ping every layer. Our on-call team responds within 15 minutes and mitigates first, then we run the full post-incident routine. 

A big contributor here is client isolation; each brand runs on its own infrastructure slice. Most clients use less than 30% of allocated resources, so a spike or bug doesn’t cascade to others.

EGR: What’s next on the roadmap to strengthen these stability metrics?

DR: We’re migrating more and more components to Kubernetes to make deployments faster, safer and fault-tolerant. If a server fails, the cluster automatically shifts workloads, and we can run multiple casinos on a shared pool while still keeping them isolated.

That directly improves deployment stability and helps reduce mean time to recovery (MTTR) when incidents happen. It won’t radically change the overall go-live timeline but will definitely make day-to-day operations more predictable.

At the same time, we’re expanding our global presence while strengthening infrastructure connectivity, DDoS protection and performance of the platform. We’re also constantly improving our monitoring workflow so we spot issues before they affect the player experience.

Denis Romanovskiy is deputy chief technology officer at SOFTSWISS.

An experienced senior technical manager, he has over 25 years of leadership in delivering complex, large-scale technical projects and programmes across diverse industries, including the last five years in the igaming sector.

Romanovskiy has successfully built and managed engineering and delivery processes in large organisations with extensive client bases, handling systems with high-load and rigorous reliability requirements.