Everyone loves a dramatic finish. And with past winners the United States now eliminated from the 2023 FIFA Women’s World Cup, some drama is guaranteed. Will England’s women bring it home for the first time ever? Will the Netherlands avenge their 2019 finals loss? Will a nation that has never made the finals – perhaps Australia, playing at home for this tournament, or Jamaica in their first-ever survival round – grab a surprise win?
After all, this tournament has already had plenty of drama. Millions of viewers shared in the heartbreak (or joy) of the US team’s sudden-death loss to Sweden in a penalty shootout on Saturday.
It doesn’t matter whether you’re a streaming service, a sports betting app, or a social media platform – that is gold. At least as long as you can survive it.
Massive events that draw global attention can be a goldmine. But if your app can’t hold up to the pressure of that kind of traffic surge, it’s going to feel like that goldmine is collapsing on top of you.
So, how can you make sure your app is up to the challenge?
Test, test, test.
Don’t trust that your infra can stand up to World-Cup-finals loads just because your cloud’s sales reps told you that it can. In any kind of business that’s likely to encounter traffic surges, you should be regularly testing your infrastructure so that you know what it can handle, and what kinds of unexpected issues you might encounter when demand for your application goes through the roof.
Testing past the breaking point is also a good idea. What happens when your system does go down? How long does failover take? Are you losing any data? A lot of people are surprised to discover that their replicated database is still vulnerable to data loss – that is not a surprise you want when the stakes are high.
Build for resilience and availability.
If breaking the application will impact the customer experience at all, you need to make sure that the application won’t break. And since everything breaks, that means embracing a distributed approach where this or that instance going down isn’t a big problem because you can quickly spin up another.
In practical terms, this generally means embracing a distributed microservices architecture for your business logic, backed by a distributed database for all mission-critical workloads in your persistence layer. Deploying an architecture like that on Kubernetes, for example, allows you to automate adding and removing pods as needed, ensuring that even if this or that server encounters an issue, your application can still spin up the resources required to run both the business logic and the database.
Go multi-region, or multi-cloud.
When you’re dealing with a global traffic surge, it’s not just about staying online, it’s also about maintaining performance so that users have a good experience. Noticeable lag is not a good experience, so you’ll likely want to locate application services and user data as close to your users as possible.
(Increasingly, you may also be required to do so by data and privacy regulations, so take extra care in choosing and deploying your database if you serve a global client base. When you are required to store data in the same country as the user, for example, it pays to have chosen a database that is built for this, rather than having to try to bolt that feature onto a legacy database that’s already in production.)
Automate your scaling.
You don’t want to be paying for “World Cup finals” level infrastructure every day if you don’t need it every day. Choose tools or build services that can be quickly and automatically scaled up and down, so that if traffic spikes your infra can expand to handle it without any need for manual intervention.
KISS.
OK, there’s no such thing as a simple application that can stand up to the weight of millions and millions of World Cup viewers. Achieving that kind of scale is complex.
But that complexity makes it all the more important that you keep things simple wherever you can:
Don’t code your own bespoke systems for multi-cloud. Choose tools that were built to support it.
Don’t shard your database, choose a database that handles data partitioning natively and automatically.
Opt for managed services where you can (so long as they can offer the proven scale, availability, and resilience you need).
Because one thing you don’t want on game day is to encounter an issue that has your team frantically searching through your codebase, trying to fix some issue caused by bespoke code when you could have just used an existing, proven tool that does the same thing.
Whether it’s England winning the World Cup, Black Friday, or something else, sooner or later you’re going to encounter one of these massive events that affords the opportunity for either triumphant success or humiliating defeat. You want to take home the gold medal, and build an application that can handle the pressure at the absolute highest level.
