Can the website handle campaign traffic? How to prepare operations before launch
A practical plan for testing capacity, configuring caching and CDN, securing backups, and establishing monitoring before an expected traffic spike.
Category: Hosting and operations
A campaign, product launch, or media coverage can send many visitors to the website in a short time. In that situation, it helps little that the solution works well on a normal business day. The operating environment must handle both the volume of traffic and the actions users take when they arrive.
Preparations should therefore be based on a specific traffic scenario, not a general expectation that the hosting “should be able to handle a lot”. The goal is to identify where the load occurs, reduce unnecessary work in the solution, and know what to do if capacity nevertheless becomes strained.
Start with the event, not the server
Before considering more capacity, you must describe what is actually going to happen. A campaign that sends users to a cached information page puts a different load on the solution than a launch where everyone is expected to search, log in, fill out a form, or complete a purchase.
Clarify at least the following:
- When is the traffic expected to start, and how long might the peak last?
- Which countries or regions will the users come from?
- Which landing pages will receive the traffic?
- What actions will the users take?
- Which external services does the user journey depend on?
- What are the consequences if the website becomes slow or unavailable?
A specific scenario could be that a newsletter is sent to the entire customer base at nine o’clock, directing recipients to a product page with an order form. The test must then include the product page, the form, the confirmation, and any integrations with the CRM or email system. Measuring only the front page is not enough.
Map the entire chain to the user
A modern website is delivered through several layers. The request may pass through DNS, CDN, and firewall before reaching the web server, application, database, and external services. The bottleneck can be anywhere in this chain.
Create a simple overview of the components the campaign depends on. Note who is responsible for each part, how it is monitored, and what can be done if it fails. This makes it easier to distinguish hosting problems from errors in, for example, the payment solution, form service, or an integration.
Uptime at the hosting provider is only one part of the picture. A server can be available while checkout is failing, the database is responding too slowly, or login is blocked. For the business, it is the service as a whole that must work.
Test realistically before the traffic arrives
A capacity test should replicate expected usage, but be conducted in a controlled manner. Start with a low load and increase it gradually. Monitor response times, errors, processor usage, memory, database activity, and the number of concurrent processes while the test is running.
Consider testing several types of traffic separately:
- Visits to pages that can be delivered from cache.
- Visits to dynamic pages such as search, login, and the shopping cart.
- Form submissions or completed purchases.
- Calls to integrations that must respond before the user can proceed.
This kind of breakdown shows what is actually creating the load. If ordinary page views are handled well but the form becomes slow, you should investigate form processing and integrations before purchasing a larger server.
The production environment provides the most realistic results, but load testing there can affect real users and data. Therefore, agree on the timing, scope, and stop criteria with the operations provider. In a test environment, the server configuration, database, caching, and integrations must resemble production closely enough for the results to be useful.
Use caching to reduce the workload
Caching allows pre-generated content to be delivered without the application and database rebuilding the page for every visitor. For a campaign page, this can provide significant relief, provided the page can actually be cached.
Make sure the most important landing pages are cached and that the cache is populated before the campaign starts. Also test what happens when content is published or updated. Incorrect cache purging can cause all traffic to be sent directly to the application at once.
Not all content should be cached in the same way. Shopping carts, account details, personalised prices, and form confirmations usually need to be handled dynamically. A good configuration clearly distinguishes between public content and user-specific responses. Errors here can be both a performance issue and a privacy issue.
Let the CDN handle as much traffic as it can
A CDN can deliver images, stylesheets, scripts, and cached web pages from nodes closer to the user. This reduces the load on the main server and can provide more consistent delivery when traffic comes from multiple geographic regions.
However, a CDN does not automatically solve capacity problems in dynamic functions. If every visitor has to send data to the application, look up information in the database, or wait for an external service, the main environment will still have to do the work.
Before launch, you should check which responses are delivered by the CDN, which go to the main server, and how long content is stored. Also ensure that there is a safe method for clearing or updating the cache if incorrect content is published.
Choose an operating environment that can be changed quickly
When traffic spikes are expected, flexibility is often more important than high capacity all year round. The operating environment should be scalable in a controlled manner, either manually or automatically. At the same time, you must know what scaling actually covers.
More capacity on the web server is of little help if the database, file system, or an external integration is the limitation. Therefore, ask how the environment handles increased traffic at each layer, how long a capacity change takes, and whether the change requires downtime.
The choice between shared hosting, a managed platform, a virtual server, and more complex cloud solutions should be assessed based on expertise and operational needs. An advanced environment is not necessarily safer if no one is responsible for configuration, updates, and incidents. The best environment is one you can understand, monitor, and restore within the organisation’s requirements.
Monitor capacity and functionality at the same time
During the campaign, you need more than an alert that the front page is unavailable. Monitoring should show both technical status and whether the most important action is working.
Current signals include:
- Response time and error rate for key pages.
- Load on the web server, application and database.
- Percentage of traffic served from cache and CDN.
- Queues, timeouts and errors in integrations.
- Whether forms, login or payment can be completed.
- Unusual changes in the number of orders or submissions.
Determine in advance which thresholds should trigger action. Alerts without a recipient or agreed response provide little value. It must be clear who investigates, who can increase capacity, and who decides whether to stop the campaign.
Ensure a way back
A backup is necessary before launch, but it must suit the solution and the pace of change. For an online store, new orders may come in while an issue is being investigated. A full database rollback could then overwrite valid transactions.
Therefore, clarify what should be restored in different situations. An error on the campaign page may perhaps be resolved by rolling back code or content without affecting the database. A damaged database requires a different plan. Verify that the latest backup has completed, that it is stored separately from the production environment, and that those responsible know how to initiate recovery.
Freeze unnecessary changes
Immediately before a major campaign, you should limit changes that are not necessary. Updates to software, plugins, themes, server configuration and integrations can introduce errors that become difficult to distinguish from capacity issues.
This does not mean that security-critical maintenance should be postponed without careful consideration. The point is to plan maintenance so that the solution is updated and tested well in advance. Set a time when the configuration is frozen, and require a clear assessment before anything is changed after that point.
Create a simple launch-day plan
A practical operations plan does not need to be extensive. It should be short enough to be used in practice and include:
- Campaign start time and expected traffic peak.
- Names and contact details for technical, editorial and business responsibility.
- An overview of the dashboards and alerts to be monitored.
- Thresholds for scaling, troubleshooting and, if necessary, stopping the campaign.
- Procedure for rolling back the latest change.
- A backup version of the landing page with fewer dynamic features.
During the launch, one person should coordinate decisions. Developers and operations staff must be able to work on the issue without parallel requests from multiple parties. At the same time, the business must have someone who can adjust advertising, mailings or customer communications if technical capacity becomes strained.
Use the experience to improve normal operations
After the campaign, you should gather measurements and incidents while they are still fresh. Compare expected traffic with actual traffic, and identify which components approached their limits. Also note what worked well, so that the next launch does not start from scratch.
The most important benefit is not simply that one campaign goes well. The work provides a better overview of the operating environment, more precise monitoring and clearer accountability. This makes the website easier to maintain and reduces the time between a problem arising and the right action being taken.
