Most online stores do a large share of their annual revenue in a handful of days. A holiday weekend, a product launch or a single flash sale can bring more traffic in one hour than a normal week.
The good news is that peak days are predictable. You know the date, you have last year's numbers, and you control the promotions that drive the spike.
Start with a load estimate, not a guess
Pull last year's peak from your analytics and server logs, and look at the busiest minute, not the busiest day. Daily totals hide the spike that actually breaks systems, which usually arrives when an email campaign lands or a countdown ends.
Suppose last year's busiest hour had 60,000 sessions and marketing expects twice that this year. At 120,000 sessions with an average of 10 page views each, the origin must serve about 1.2 million page views in the hour, or roughly 330 per second on average. Traffic inside an hour is not flat, so multiply by 2 to 3 for the peak minute and plan for around 1,000 dynamic page requests per second, plus API calls from the cart and search.
Little's law then turns rate into concurrency: requests in flight equal arrival rate multiplied by response time. At 1,000 requests per second and 300 ms per request, about 300 requests are being processed at any moment. If each application worker handles one request at a time, you need at least 300 workers across the fleet, and more to leave headroom for slow requests and a failed node.
- Orders. At a 3 percent conversion rate, 120,000 sessions produce about 3,600 orders in the hour. That averages one per second, but plan for 5 to 10 per second at the peak minute.
- Bandwidth. A 1 Gbps port moves about 125 MB per second. If uncached HTML pages average 100 KB, 1,000 pages per second already consumes most of that port before images and scripts.
- Headroom. Size for at least 1.5 times the estimate. Forecasts are usually wrong in the direction of more traffic, and bots add load that analytics never counts.
Push as much traffic as possible to the edge
A content delivery network should serve every static asset: images, CSS, JavaScript and fonts. If the CDN serves all of them from cache, origin load drops by an order of magnitude.
Category pages, product pages and the home page are often identical for everyone who is not logged in and has an empty cart. Caching them at the edge for even 30 to 60 seconds turns thousands of identical requests per minute into one origin request per page per edge location.
- Cache keys. Strip tracking parameters from URLs before caching, or every campaign click becomes a cache miss.
- Purge strategy. Decide in advance how price and stock changes reach cached pages, by short TTLs, targeted purges or both.
- Application cache. Inside the origin, keep sessions, cart data and expensive query results in an in-memory store such as Redis so the database is not asked the same question thousands of times.
- Search. Serve search and filtering from a dedicated search index rather than from SQL queries against the product tables.
Size the database for the write path
Read traffic can be cached and replicated. Writes cannot. Every order touches the order table, line items, inventory, payment records, customer data and often an audit log, which can easily mean 20 to 50 writes per order.
Start by making sure the working set fits in memory. Check the slow query log from recent busy days and fix missing indexes now, because a query that takes 200 ms at normal traffic can lock tables for seconds at peak.
- Connection pooling. Put a pooler in front of the database. Hundreds of application workers opening their own connections will exhaust the database before the CPU is busy.
- Read replicas. Send catalog reads, reporting and back-office queries to replicas so the primary handles orders.
- Hot rows. A single heavily discounted product can turn one inventory row into a lock contention point. Reserve stock with an atomic counter in an in-memory store and reconcile to the database, or split the stock across several rows.
- Background jobs. Pause or reschedule heavy batch work, feed exports and analytics jobs for the duration of the event.
Isolate checkout from everything else
When a store degrades under load, the goal is to keep taking money. Browsing can be slow for a few minutes. Checkout cannot.
In practice this means a separate pool of application servers, or at least separate workers, for cart and checkout routes, so a flood of category page requests cannot starve payment requests. Payment gateways, tax calculation, fraud scoring and shipping rate services all need short timeouts, retries with limits and a defined fallback, such as accepting the order and running fraud checks asynchronously.
- Feature flags. Prepare switches that turn off recommendations, reviews, personalized widgets and live chat. Each one removes load without a deployment.
- Third-party scripts. Audit the tag manager. Every analytics and marketing script on the checkout page is a dependency you do not control.
- Waiting room. A virtual queue that admits visitors at a set rate is better than a site that fails for everyone. Configure and test it before you need it.
- Bot control. Rate limit by IP and session on cart and login endpoints, and keep DDoS mitigation in place. Inventory bots and credential stuffing tend to arrive with the sale.
Load test the way customers actually shop
Real shoppers browse categories, search, open product pages, add items to the cart and a small share of them check out. Build the test from those journeys, with a mix that matches your analytics, for example 70 percent browsing, 15 percent search, 10 percent cart activity and 5 percent checkout.
Run the test from outside your network, through the CDN, against an environment that matches production in size and configuration. Tell your CDN, hosting and DDoS mitigation providers before you start, because a large test can look exactly like an attack.
- Ramp test. Increase load in steps up to 1.5 to 2 times the estimate and note where latency starts to rise. That point is your real capacity.
- Spike test. Jump from normal traffic to peak in under a minute, the way an email campaign behaves. Autoscaling that takes five minutes to add capacity will not help here.
- Soak test. Hold peak load for two to four hours to expose memory leaks, connection leaks and log volumes that fill disks.
- Repeat. Each test finds the first bottleneck. Fix it, run again, and continue until the limit is comfortably above the forecast.
Write the runbook and wire up monitoring
During an incident people make worse decisions than they do at their desks on a quiet afternoon. A runbook moves the decisions to the quiet afternoon. It should name who is in charge on the day, who talks to the business and to customers, who can approve a change, and what the agreed responses are for the most likely problems.
Monitoring needs two layers. The technical layer covers latency, error rates, saturation and traffic for every tier: CDN hit ratio, application response time, worker utilization, database connections, replication lag and queue depth. The business layer is often more useful: orders per minute, checkout success rate, payment authorization rate and cart abandonment.
- Thresholds. Write down what normal looks like for each metric at peak, based on the load tests, so the team can tell a busy system from a failing one.
- Pre-agreed actions. For example: if checkout p95 latency exceeds 2 seconds for 3 minutes, disable recommendations; if it exceeds 4 seconds, enable the waiting room.
- Rollback. Document how to revert the last deployment and how long it takes. Test it once.
- Contacts. List escalation contacts for the hosting provider, CDN, payment gateway and any other critical vendor, with their support channels and hours.
The week before: a checklist
By the last week the work should shift from building to confirming. Use the time to verify that everything prepared earlier is in place and to remove surprises.
- Change freeze. Freeze code and infrastructure changes except for fixes approved through the runbook.
- Certificates and domains. Check TLS certificate and domain expiry dates. Lower DNS TTLs in case you need to redirect traffic quickly.
- Capacity. Confirm that extra servers are provisioned or reserved, not just planned. Scaling up from zero on the day leaves you exposed to provider capacity limits and warm-up time.
- Backups. Verify the latest database backup by restoring it, and confirm point-in-time recovery works.
- Promotions. Test every discount code, bundle rule and price change in staging with real cart combinations.
- Inventory and catalog. Load sale stock, images and descriptions in advance and warm the caches for the top products.
- People. Publish the on-call schedule, the communication channel and the status page process. Make sure the people on call have the access they need.
On the day
Scale up hours before the event, not when graphs start climbing. Warm the caches by requesting the top category and product pages.
Change nothing that is not in the runbook, and log every decision with the time it was made. If something breaks, the incident lead decides, the team executes the agreed response, and the business contact keeps marketing and customer service informed so they can pause a campaign or update customers. Within a week, hold a review while the data is fresh and record the real numbers.
How Vonahost can help
Vonahost's managed cloud runs on its own platform, on AWS and on Google Cloud, and includes CDN, Redis, Elasticsearch, staging environments, backups and monitoring, which covers several of the layers described above. For the database and other components that benefit from single-tenant hardware, Vonahost dedicated servers offer AMD EPYC processors, local NVMe storage, a dedicated 1 Gbps port with unmetered traffic and Arbor DDoS mitigation, deployed in the region you choose.
If you are planning for a peak event, the useful first step is to share your traffic estimate and current architecture. Every Vonahost proposal states the configuration, location, responsibilities and monthly price in US dollars, and you choose the country where each server runs.