ESPN Website Meltdown – Fantasy to Nightmare
ESPN made news headlines this past weekend – the bittersweet kind. Unfortunately, the news highlighted that ESPN’s fantasy football app was crashing, on the first Sunday of the NFL season. Where’s the “sweet” part? The crash likely signals a huge amount of user popularity.
We see these types of stories often during so-called “surge” events, like when Black Friday takes down a retailer. Why? Often, it’s the database that’s been swamped in the process.
The application-to-database connection is fragile, because applications have to directly tie into the database and the coding of the app must match the database infrastructure. For example, if the database has multiple database servers that can all respond to an inbound request, the application needs to know which type of server to send its request to. While those changes can ensure a better response time, the work isn’t trivial – a programmer must go through 100s of 1000s of lines of code to program how to handle reads vs. writes – and it can lead to errors.
Any recent changes by ESPN to increase database capacity or update the app could jeopardize that fragile connection. If ESPN recently modified the application to talk to different database servers, for example, the team might have accidentally introduced a “bad” query that the database can’t handle or might have changed how the application talks to the database and broken that connection.
Organizations that are anticipating a surge in traffic have a number of best practices they should follow to ensure a smooth experience for their customers, including:
- Freezing code early – Despite the understandable desire to make the app or site as current as possible, it’s essential for engineering to force a code freeze many weeks before the “go live” date. Quality assurance (QA) and other testing needs need adequate time to ensure the updated site or app is working as needed.
- Load testing – A big part of that testing work needs to come in the form on load testing. After a QA team has performed functional testing – that is, does each feature work – the next step is to see how the code performs when it’s swamped with traffic. The key is to perform this load testing with traffic that’s as close to production traffic as possible.
- Increasing resiliency at the data tier – The lifeblood of any app or site is data – without, you’re down. To build in resiliency at this layer, organizations need to employ techniques such as database scale out, to have multiple copies of the data available, and database load balancing, to ensure traffic is serviced by the fastest-responding server to the user.
- Enabling redundancy in all network services – Beyond the data tier, organizations need to make sure the rest of the technology stack has all the redundancy built in as possible. Web server infrastructure, along with web load balancers, are critical, as is network redundancy into both the web farms and the database server clusters. If you’re hosting the app or service in the cloud, ensure a redundant version is available in an alternate cloud region.