What a Black Friday Traffic Spike Costs on a Fixed VPS vs an Auto-Scaling WordPress Cluster

Ask a WooCommerce store owner about hosting and the conversation turns to one week in November. The store we will use as an example, a specialist outdoor-gear retailer we will call Ridgeway Supply, takes roughly 30% of its annual revenue between Black Friday and the following Monday. Its hosting decision is really a decision about that week. This post lays out the numbers for two ways of handling it: a VPS sized for the peak, and a WordPress cluster on MassiveGRID PaaS, built on Virtuozzo Application Platform (formerly Jelastic), that resizes itself hourly.

The two ways to buy peak capacity

Ridgeway's normal weekday sees about 3,000 sessions and 120 orders. On Black Friday the store has measured 45,000 sessions and 2,800 orders, with a checkout rate that makes every minute of slowness expensive. A fixed server has to be bought for that day. A pay-per-use platform can be bought for the average day and allowed to grow.

The difference sounds obvious until you price it. A dedicated or VPS plan large enough for the peak, say 16 vCPU and 64 GB of RAM with fast storage, runs several hundred dollars a month at most providers, twelve months a year, and it still has a ceiling. If Black Friday is 20% bigger than last year, the ceiling is the outage. Renting a second server for the week means a migration, a DNS change and a rollback plan, which is why most small retailers do not bother and simply overpay all year.

How the platform meters capacity

MassiveGRID PaaS measures every container in cloudlets: one cloudlet is 128 MiB of RAM plus 400 MHz of CPU, and MassiveGRID's published rate is $0.003372 per cloudlet-hour, or $2.46 per cloudlet per month. Each hour, a node is charged for the greater of its peak RAM usage and its average CPU usage, not the sum of both, and never for RAM the kernel uses as disk cache.

Two settings per node decide the bill. Reserved cloudlets are committed in advance, charged whether used or not, and discounted in return. Dynamic cloudlets set a scaling limit; the platform adds them when the application needs them and removes them when it does not, within the same hour. Setting the scaling limit is setting the maximum budget for that node. Nothing about this requires a restart or a migration, which is the whole point.

The WordPress Cluster Kit adds a second dimension: horizontal auto-scaling. The installer offers three strategies for the application-server layer. Low load adds a LiteSpeed node when the layer's average load exceeds 70%, medium load adds one above 50%, and high load adds two nodes above 30%, each scaling back down to two nodes when load drops below the release threshold. The platform evaluates the layer's average every minute over the window you configure, places each new node on a different physical host, and adds it to the load balancer automatically.

Ridgeway's normal week, in cloudlets

Ridgeway's cluster on a quiet Tuesday runs two LiteSpeed application servers at about 6 cloudlets each, a load balancer at 2, a two-node MariaDB primary-primary cluster at 4 each, Redis at 2 and shared storage at 1. That is 25 cloudlets, and in practice the hourly charge is a little lower because CPU averages below the RAM peak on most nodes.

At the published dynamic rate, 25 cloudlets for a 730-hour month is about $61.50 before volume discounts and before the reserved-cloudlet discount Ridgeway takes on the baseline it always uses. Disk, external traffic and the public IP are metered separately, but for a store of this size they are a small addition. Compare that with the several hundred dollars a month for a peak-sized VPS and the gap is already large before the peak arrives.

Black Friday, hour by hour

From 06:00 on the Friday, traffic climbs. Vertical scaling reacts first: the LiteSpeed nodes' dynamic cloudlets rise from 6 towards their scaling limit of 16 as PHP workers and the LiteSpeed cache consume more memory. The platform's smart auto-configuration adjusts the number of LiteSpeed worker processes to the new cloudlet count without a restart, so the extra capacity is usable immediately.

At about 09:00 the layer's average CPU crosses the medium-load trigger of 50% for the configured five minutes, and the platform adds a third LiteSpeed node, cloned from the master because the layer is stateful, complete with the deployed theme and the LiteSpeed cache configuration. The load balancer starts sending it traffic within a couple of minutes. By 11:00 there are five application servers. The MariaDB nodes have grown to 10 cloudlets each. Redis holds the WooCommerce sessions so a shopper whose next request lands on a different node keeps their cart.

The peak hour costs roughly what you would expect from the arithmetic: five application servers at 16 cloudlets, a balancer at 4, two database nodes at 10, Redis at 4 and storage at 1 is 109 cloudlets, or about $0.37 for that hour. Ridgeway's whole Black Friday, with traffic staying elevated for eighteen hours, comes to under $6 in compute above the normal day. The following Tuesday, when load drops below 20% for ten minutes, the extra nodes are removed one by one and the bill returns to the baseline.

The number that matters more than the bill

The compute saving is real but it is not why Ridgeway moved. The reason is the 20% question. On a fixed server, growth beyond the plan is an outage during the most valuable hour of the year, and the only mitigation is buying an even larger server. On the cluster, growth beyond expectation is one more node added by a trigger the owner set in a dropdown, with a ceiling of 16 nodes per layer that a store this size will not approach. The 100% uptime SLA covers the infrastructure underneath, and the anti-affinity placement means the five application servers are on five different physical hosts, so a hardware fault during the peak takes out one fifth of capacity, not the store.

There is a second-order effect on conversion. Checkout latency at Ridgeway's old host climbed past four seconds at peak. With capacity added by the minute, the LiteSpeed cache serving category pages and Redis handling sessions, the store's checkout stayed under a second and the abandonment rate during the sale matched a normal week. For a store where the peak is a third of the year, that difference dwarfs the hosting line on the accounts.

What to set before the sale

• Raise the scaling limits early. Vertical scaling can only grow to the dynamic cloudlet ceiling you set per node. Set the application servers and database nodes high enough for the peak a week ahead; the limit costs nothing until it is used.
• Pick the high-load strategy for the week. Adding two nodes at 30% is aggressive on a normal day but right for a sale, because stateful cloning takes a minute or two and you want the node ready before the surge, not after. Switch back afterwards.
• Warm the cache. Crawl category and product pages after the third node joins so the LiteSpeed cache is populated on every server.
• Take a backup at 05:00. The WordPress Backup/Restore add-on puts files and database on a separate storage node; a known restore point before the busiest day is cheap insurance.
• Watch the load alerts. The platform emails when any node approaches its limits; forward them to the on-call channel or use the Slack alerts package.

Frequently Asked Questions

Is the WordPress cluster more expensive than a VPS on a normal day?

For a small store, usually not. The example baseline of 25 cloudlets is about $61.50 a month at the published dynamic rate before discounts, and it already includes a load balancer, two application servers, a replicated database, Redis and shared storage. A VPS priced for the same peak is typically several times that, and a VPS priced for the normal day cannot serve the peak.

How fast does horizontal scaling react?

The platform evaluates the layer's average load every minute over the window set in the trigger (from one minute upwards) and then creates the node. In stateful mode the new node is cloned from the master, so allow one to two minutes before it takes traffic. Vertical scaling is immediate, which is why the two work together: cloudlets absorb the first minutes of a surge while new nodes are prepared.

Do I need to change WooCommerce for a multi-node cluster?

No. The cluster kit configures Redis for object caching and sessions, shared storage for uploads and a load balancer with session affinity, which are the three things that break WooCommerce on a naive multi-server setup. Standard plugins and themes work unchanged.