Kirill Polishchuk, Senior DevOps Engineer, shares the playbook on resilience and readiness ahead of the world’s biggest tournaments.
Super Bowl 2026 saw 81.4 million geolocation checks on one single game day. March Madness Final Four Weekend tallied 145.6 million. The first 14 days of the World Cup clocked in at 800.8 million.
This is the story of how GeoComply manages it all without a hitch.
We sat down with Kirill Polishchuk, Senior DevOps Engineer at GeoComply, to talk through how the team approaches global sporting moments: the process, the decisions, and the thinking that goes into making sure our infrastructure remains the quiet, reliable force running beneath every exciting on-field moment.
checks on game day
Final Four weekend
first 2 weeks
But first, let’s set the scene
When a major sporting event kicks off, millions of fans open their apps at the same time. And then open them again when something changes the course of play.
That means the infrastructure underneath (the geolocation checks, identity verifications, fraud signals, etc) is absorbing enormous, sudden spikes in demand.
All of this happens in seconds.
For operators, the stakes are real. If a platform slows down or goes dark at the moment someone is trying to place a bet, that fan doesn't wait. They walk away. And in a market where first impressions and seamless experiences drive loyalty, a technical failure doesn't just cost a session. It costs a customer.
This is the world GeoComply's infrastructure team prepares for every season. Super Bowls. March Madness. Championship weekends. And most recently, for the first time at this scale: the World Cup.
What was different about the 2026 World Cup?
The 2026 tournament presented a genuinely new challenge, thanks to new markets and new fans:
Hosted across three North American countries for the first time ever, with games taking place in US time zones, it landed squarely in the middle of the world's most developed sports betting market.
Brazil, newly regulated in 2025 and now considered to be one of the five largest betting markets in the world, was playing on the biggest stage it had ever competed on in a live regulated environment.
Canadian and American bettors, traditionally NFL-first, were showing up for a different flavour of football in numbers no one could fully forecast.
There was no direct precedent. No "last year's World Cup" to benchmark against with any real precision. The preparation had to be built from intelligence, not habit.
And that’s the exact mindset Kirill and the team built their playbook around.
The World Cup is one of the most watched sporting events on the planet. What was your first reaction when you started thinking about what it meant for GeoComply's infrastructure?
This was something genuinely new for us. The previous World Cup was four years ago, in December, in a different time zone. This one demanded a different level of attention.
Honestly, our first assumption was that it would mainly be a Brazil story. We have US environments and we have Brazil environments, and we figured the World Cup traffic would be concentrated on the Brazil side.
But these games are happening in American, Mexican, and Canadian cities. For regulated iGaming, that means a lot of live activity in US and Canadian time zones. After talking with our teams and with customers, we realized our partners were expecting real volume from US bettors.
So we had to shift our thinking. And that shift happened through conversations with our partners. Once we heard how they were preparing, it became clear this wasn't just a Brazil event. It was a North American one.
How did the preparation process actually work? When did it start, and who was involved?
Preparation started months before the tournament. Each team member took on a different piece of the puzzle.
Partner collaboration was a major aspect. Talking to our customer support team and our partners. The goal was to get their expectations directly. What are you planning to run? What are you anticipating?
We also went deep with our internal teams to understand what was coming down the product roadmap before the tournament: any new technology releases, infrastructure changes, things we needed to account for.
The third major pillar was intelligence. We focused on what we knew from previous comparable events and how to frame our benchmarks.
By early June we had a preparation framework in place. But the important thing is: it's not one meeting where someone says "we're ready." It's a sequence. We identify the problems and challenges, we address them one by one, and the work shapes the plan.
Readiness isn't a declaration, it's a process.
You mentioned benchmarking. How do you stress-test for an event with no direct precedent?
The Super Bowl is always our benchmark. It's historically the single highest-traffic event we see. So the logic is: if we can handle Super Bowl peaks, and we're confident World Cup won't exceed them, we have our answer.
Even accounting for Brazil, for the tournament being in North American time zones, for the advertising push from operators, we expected the peak traffic to land below Super Bowl levels.
That gave us a clear baseline. We sized our infrastructure against Super Bowl volumes, confirmed we had headroom, and added buffers on top. You always add buffers. There's no event where we scale to exactly the expected number and leave it there. If something goes unexpectedly, you want room to absorb it.
Walk me through what the actual preparation looks like under the hood. What does scaling for an event like this involve?
The most important thing to understand is the difference between stateless and stateful components.
Stateless components, meaning our application layers, can scale quickly. If traffic spikes, we can add capacity fast.
Stateful components, specifically our database layer, are different. You can't spin up a new database in the middle of a match. It takes days, not hours, and it's expensive. So the preparation there happens well in advance.
For the World Cup, we analyzed whether we could safely run our database layer at a certain threshold of utilization without scaling it to maximum, and we confirmed we could. Super Bowl benchmarks supported it. So we went with that.
In terms of scale: at Super Bowl levels, we're running roughly three times the instance count of a regular period. For the World Cup, we came in below that. We've actually been able to tune further as the tournament has progressed, because real traffic data has given us real confidence.
All of this preparation needs to happen across many distinct environments. Each one has its own scaling configuration. Verifying that everything was applied correctly, across every environment, is its own checklist item. A misconfiguration that goes unnoticed in one environment can create a problem on game day that nobody anticipated.
Standard auto-scaling sounds like it would solve some of this. Why doesn't that work for betting infrastructure?
Auto-scaling is actually the gold standard a lot of companies use. It scales your infrastructure automatically without you having to do anything. But for us, it doesn't work.
Our traffic can be flat and then spike 10x in the next second. There's no way for auto-scaling to catch up to that.
Our product team is very clear: we need to geolocate as fast as possible, return responses as fast as possible. We can't put a big buffer in front of our infrastructure and ask clients to wait a minute for a response. That's not our business.
Think about it from the bettor's perspective. Someone is putting serious money on a bet. They need to know immediately whether it went through. Speed and agility are our primary values. That's why we scale to our maximum expected transactions per second in advance, not after the spike hits.
What does your monitoring approach look like going into a major event?
Most people think of monitoring as something that tells you when something's wrong. We use it differently. It's a predictive tool.
Our alerts are configured at less than 50% utilization. Not 80%, not 90%. We get a signal when there's still significant headroom, but we're aware. We can investigate, decide if we need to add capacity, and act before anything approaches a threshold that matters.
By the time most systems are alerting, we've already seen it coming and either addressed it or made a conscious decision that we're fine.
On Super Bowl kickoff night, the whole team is online. All hands on deck, watching together. It's intense, but it's also something we genuinely look forward to. You spend months preparing. And then you get to watch it all hold.
So it's the day before a big game. What's on your pre-game checklist?
Going into a major event, the pre-game checklist covers three things: monitoring, scaling verification, and communication:
And on the partnership side, our customer success teams reach out directly to understand what they're expecting, based on the campaigns they're planning to run. We want to know before game day, not find out from a spike.
What does your redundancy setup look like if something unexpected does go wrong?
We think about redundancy in layers.
The first layer is our stateless components, distributed across multiple availability zones. If one zone has a problem, the load spreads automatically.
The second layer is our database infrastructure. Because databases are stateful, you can't write to multiple sources simultaneously. If the primary goes down, there's a window of exposure. We have failure rules in place that switch to a standby database within seconds. For most systems, that kind of switchover time is considered fast. We treat it as the floor, not the ceiling.
The third layer is our queuing mechanism, introduced last year. If something unexpected causes a spike we haven't scaled for, or if a component temporarily can't accept traffic, transactions queue rather than error. We can hold traffic while the system catches up. The player doesn't get an error message. For a bettor placing a high-stakes wager, that matters enormously.
If something catastrophic happened at the infrastructure level, like a major cloud provider outage, we have a disaster recovery site that serves as a backup to our primary infrastructure. We stayed live through last year's AWS outage without customer impact. Our live-live failover is there if we need it.
The goal with all of this is to never need the deeper layers. We build enough resilience into the primary environment that the failover is a last resort, not a routine tool. But it exists, and we're confident it can hold.
The World Cup is a six-week tournament, not a four-hour game. How do you handle that operationally?
That's actually one of the most interesting infrastructure challenges of this event. The Super Bowl is intense, focused, and over. You scale to maximum, you watch it happen, you scale back down. The World Cup is a slow burn. Multiple games a day, every day, for six weeks.
Scaling to Super Bowl levels for six straight weeks would cost significantly more. That's not an infrastructure problem, it's a business decision. The right answer wasn't to overspend. It was to be smarter about it.
So we divided the tournament into six gates. At each gate, we observe what the traffic actually looked like in the previous stage, compare it against our predictions, and tune our infrastructure for the next one. It's a continuous calibration rather than a fixed setting.
After the first gate, we had enough real data to downscale our instance count and maintain full confidence in our safety thresholds. That's not cutting corners. That's what it looks like when preparation meets real-world data and you have the processes to act on it intelligently.
The energy builds differently than the Super Bowl. But the systems hold the same way. And when the final arrives, the team will be there for that one too.
The playbook
What to ask your infrastructure partner before a major event
What Kirill described isn't a set of heroic fixes deployed under pressure. It's a repeatable process, documented and built on years of refining what works. Here's the framework, distilled for any operator or platform thinking about infrastructure readiness going into a high-stakes event.
Final checks happen in the last month. The real work, load testing, scaling decisions, security patches, infrastructure updates, needs runway. If your partner is still figuring out their approach two weeks before a major event, that's a signal.
The best pre-event intelligence comes from a combination of sources: historical benchmarks, internal load testing, and direct operator input. If your infrastructure partner isn't asking what you're planning to run, your advertising load, your expected acquisition push, your campaign timing, they're missing a layer of signal that matters.
In betting, the spike is instantaneous. A goal is scored; the market moves in seconds. If your infrastructure partner sizes for checks per minute, they're building for a different business. The question to ask: what does your system look like in the single worst second of the event, not the worst minute?
Databases can't be scaled on the fly during a live event. The question isn't whether your partner can react to traffic. It's whether they've already sized the right components days in advance. If they're relying entirely on auto-scaling, ask specifically about their database layer.
Every serious infrastructure setup has layers. The question is how fast each one activates and how much the end user feels it. A within-seconds database switchover. A queuing layer that holds transactions without erroring. A DR site that can absorb traffic if the primary provider has issues. Ask for specifics, not assurances.
A Super Bowl-style approach applied to a six-week tournament will either overspend or under-prepare. A partner that's thought about this will have a phased approach: observe real traffic, calibrate, adjust. Static scaling for a dynamic event is a red flag.
Monitoring that only alerts when something is already wrong is reactive infrastructure. Alerts at 40% utilization mean there's still time to act. Ask where their thresholds are set and what happens when they trigger.
A partner that can hand you a document at the end of a single review meeting and say "we're ready" is a partner that hasn't gone deep enough. Real readiness is demonstrated through a series of communications: here are the problems we identified, here is how we addressed them, here is what's still open. If you're seeing the work, you can trust the outcome.
GeoComply has processed billions of location checks across major North American sporting events for over a decade. Zero compliance fines. 99.999% uptime track record. The World Cup is the newest test. So far, green across the board.
Want to talk through what event readiness looks like for your platform? Set up a meeting with our experts.
Kirill Polishchuk | Senior DevOps Engineer
Kirill Polishchuk is a Senior DevOps Engineer at GeoComply, where he has spent over six years building and stress-testing the infrastructure that keeps some of the world's largest digital sports events running without a hitch. With a decade of experience spanning system administration, database architecture, and multi-cloud infrastructure, Kirill specialises in capacity planning at scale, translating raw transaction data and load projections into systems that hold when it matters most.
