Products & Services
From the industry's best ticketing system to unified food & beverage and retail operations, Gateway offers world-class solutions to increase revenue.
This blog post was reproduced on Gateway’s Blog in partnership with Queue-it. The original blog post can be found right here.
How does high traffic actually crash an attraction’s eCommerce website or app? Many blogs will tell you that high traffic can crash a site. But if you don’t understand why this happens, how can you expect to avoid the problem? For example, when your attraction sets tickets on sale for big events like Haunt Nights during the Halloween season, or when a new ride, exhibit or attraction opens, your site may see short or prolonged surges in traffic that could cause it to crash. In technical terms: system requests—made by visitors browsing your website—exceed the processing capacity resources of your site. When this happens, your website performance will slow and, for some or all users, crash entirely.
This post will show you how high traffic causes websites and apps to crash and gives you four steps to avoid website failure. The key here is planning ahead. If you can anticipate much higher than normal site traffic during certain times of the year, especially based on historical data, then you can put in place and test the right fail safes with plenty of time to ensure optimal performance.
Surging online traffic is a dream for any attraction, but especially when tickets are on sale for a big event. More traffic means more guests and more sales.
But it can also be too much of a good thing. You can be a victim of your own success. If you don’t take proactive steps to address website or app performance, peaks in online traffic can cause websites or apps to slow down and ultimately crash.
Website failures are disastrous for eCommerce operations. Imagine running a physical store where the front doors haphazardly lock and unlock, the lights flicker on and off, and products on the shelves appear and reappear at random. This is what it’s like for shoppers when an eCommerce site fails. No wonder 79% of shoppers who encounter poor website performance avoid purchasing from that retailer in the future.
To be sure, traffic overload is not the only reason websites fail. Developers introduce code errors, like when a typo at Amazon took out a backbone of the internet. Or domain name system (DNS) providers fail, like when a DDoS attack against DNS provider Dyn caused dozens of top websites to go dark.
But crashes due to high web traffic feel the most frustrating. They can stem from doing your job too well. Imagine the frustration of a Marketing or Sales Director who crafts the perfect viral campaign for your Christmas Lights event, only to see the website buckle under the pressure. There’s nothing more heartbreaking than seeing your website or app fail just when you have the most to gain.
Most blogs and articles just state traffic-induced crashes as something that can happen. But if you don’t have a deeper understanding, how can you expect to avoid the problem?
How does high traffic actually crash a website or app?
Website overload affects eCommerce sites in the same way as other websites.
The root cause is a mismatch between traffic levels and website infrastructure capacity over a given time frame. In other words, system requests—made by visitors browsing your website—exceed the processing capacity resources of your site and any third-party systems involved in the customer journey.
When this happens, your website performance will slow and, for some or all users, crash entirely.
Not all requests are equal, though. Some requests are more complex or demanding than others. And the patterns of requests are as important to understand as the amount.
This is why thinking of capacity in terms of concurrent users just doesn’t cut it. Tools like Google Analytics show data on active users right now, but it only indirectly signals the potential strain on site infrastructure. Let’s use an analogy to explain.
Picture a supermarket. Supermarkets are large and have room for many shoppers if they’re spread through the store. Some are in the frozen goods aisle, some in produce, others at the deli. The main bottleneck exists at the checkout counters, where there are only a set number of cashiers. But only a fraction of the shoppers are there. So the cashiers can keep the lines moving and the shoppers happy.
Now, imagine if everyone in the store headed for the checkout counter at the same time. The number of shoppers in the store hasn’t changed. But suddenly the cashiers are overwhelmed and the customers are frustrated.
As this flow-based understanding shows, high online traffic puts pressure on bottlenecks in the system. It is these weak links that serve as limiting factors on website capacity. The recipe for a traffic-induced crash is a high number of visitors within a short time frame mediated by the distribution of visitors along the guest journey. Your site will handle more visitors if they’re spread out than if they’re clustered in front of key bottlenecks.
Let’s look at a real-life example to make this more accessible (If you are looking for a technical discussion from a developer’s perspective, check out Website failure under load? This is why).
Meghan Markle, now the Duchess of Sussex, has a knack for causing websites to fail. It’s known as the Meghan Effect.
She has a devoted group of followers who pay close attention to everything she wears. Her fashion choices crashed an online retailer’s site not once, but twice, in 2018.
Let’s look at a customer journey to uncover just some of the behind-the-scenes legwork the site’s database is doing.
[one_sixth]Step Nr[/one_sixth] [one_third]End-user action[/one_third] [one_half_last]Request(s)[/one_half_last]
[one_sixth]1[/one_sixth] [one_third]Sees Tweet about dress, clicks on link to home page[/one_third] [one_half_last]Loads images and browser script[/one_half_last]
[one_sixth]2[/one_sixth] [one_third]Types name of dress into search bar[/one_third] [one_half_last]Complex search function must find all items that match search term(s), accounting for misspellings, product categories and features, etc.[/one_half_last]
[one_sixth]3[/one_sixth] [one_third]Browses list of products from search and clicks the dress[/one_third] [one_half_last]Loads images and browser script. Shows up-to-date inventory (size, color) information.[/one_half_last]
[one_sixth]4[/one_sixth] [one_third]Adds dress to cart[/one_third] [one_half_last]Inventory system must update to avoid over-purchasing and stay fully in sync for all other users[/one_half_last]
[one_sixth]5[/one_sixth] [one_third]Proceeds to purchase by creating guest account[/one_third] [one_half_last]Sync dynamically-entered information with membership database[/one_half_last]
[one_sixth]6[/one_sixth] [one_third]Enters shipping information[/one_third] [one_half_last]Send and receive requests from shipping plugins, like address verification and shipping costs calculator[/one_half_last]
[one_sixth]7[/one_sixth] [one_third]Enters payment information[/one_third] [one_half_last]Send dynamically-entered information to payment gateway and await payment confirmation[/one_half_last]
[one_sixth]8[/one_sixth] [one_third]Sees order confirmation[/one_third] [one_half_last]Inventory system updates stock remaining[/one_half_last]
It’s evident that there are a lot of requests for the website to handle. What’s more, there are several systems behind the scenes processing all these requests.
Each step in the guest journey adds strain to site infrastructure. Eventually bottlenecks appear where processing power is fully extended, and additional requests cannot be served.
Website visitors will experience this in the form of a website that slows down and eventually crashes, returning dreaded HTTP error pages.
In sum, when the overwhelming traffic swamps your infrastructure, the weakest link in the system will set the threshold of the entire system. And the dominoes start to fall.
Your CDN only minimizes load on static pages. Your whole website can’t autoscale because key constituent parts like the master database or payment gateways have limited scalability. Dynamic pages like checkout are extremely database-intensive, so shoppers might see your products but are left unable to pay. Inventory systems drown in so many requests you accidentally oversell. Third-party plugins like payment gateways become weak links that start failing first, out of your control.
All this put together brings your entire site crashing down.
There are three main types of scenarios where high traffic crashes websites and apps.
Put another way, there was an abnormally high traffic spike relative to your baseline traffic levels. The Meghan Effect, a feature on local TV or in a local newspaper, a particularly well-constructed social post, or overly successful marketing campaigns can all create unexpected traffic surges.
Events like Haunt Nights in autumn, Brew at the Zoo or Christmas Lights are known entities in advance. It’s no surprise that they drive above average traffic levels versus a normal day. But even with compressed events like these, precisely predicting the timing and magnitude of online traffic spikes is difficult to nail down.
Given the anticipation of the launch, and the limited capacity of your venue, these occurrences often cause short, intense spikes in traffic. This opens the possibility that your site will crash before the sale even begins.
While website crashes are an everyday occurrence, they need not be inevitable for your site.
Here are a few ways that can minimize the risk of high online traffic crashing your site.
Earlier we saw how overwhelming traffic causes overwhelming database requests. So part of your strategy should be identifying heavy database requests and then limiting the number, size, and complexity of those requests. There are many ways to build performance into your website. Not all of these will apply to all sites, but some ideas include:
Failing to prepare is preparing to fail. It might be a cliché, but it doesn’t make it less true.
Load testing is one of the best preparations you can make for web traffic peaks.
Load testing is a kind of performance testing that involves sending increasing levels of traffic to your site under controlled conditions. The aim is to help you understand how it will perform when real visitors start to hit it in big numbers. Using open-source tools, it can be almost free to run.
Because it’s an iterative process, you must allocate adequate time for load testing. Each test will reveal new bottlenecks that need fixing. Adding new code requires additional load testing. So, while it’s important to get started early, it also doesn’t make sense to test before the guest journey is complete. You might find that you need to have your landing pages and key journeys ready much earlier than expected.
Also, be sure to notify your hosting provider that you’re running the load test. Otherwise, it could look like an unwanted DDoS attack. Many providers consider an unauthorized load test a violation of terms of service.
But this preparation is well worth it. Just like a dress rehearsal is critical to a successful stage performance, load testing in advance pays dividends when it’s time for your big online sale.
You can choose to give access to a certain share of users straight away, and redirect excess users to a virtual waiting room or online queue that doesn’t strain your system.
An online queue has the benefit of managing traffic inflow along the whole user journey, keeping visitor levels where your website or app performs best. This takes the heat off bottlenecks in your own infrastructure, as well as third-party integrations like payment gateways that have capacity limitations out of your control.
Paradoxically, throttling traffic in this way can boost sales by increased conversion rates from tapping into social proof.
Gateway Ticketing Systems has partnered with Queue-it to provide our customers with a solution that controls website and app traffic surges for the times of year or big events when they expect increased site traffic. We recommend implementing Queue-it at minimum five days prior to when you feel you’ll need the service. Please speak with your Business Solutions Manager if you have any questions or would like to implement Queue-it on your site.