Server scaling: how does a site stay up under high traffic?

On the morning of a campaign, three things happen on your screen at once: sales, visitor counts, and — if your infrastructure isn't ready — error pages. Staying up under high traffic isn't about luck; it depends on an architecture designed in advance. In this article, we walk through how CDN, caching, and horizontal scaling keep your site running without interruption on campaign days, with practical steps.

Why do sites crash on campaign day?

An e-commerce site crashing under traffic rarely has a single cause; it's usually three problems stacking on top of each other: a number of concurrent requests a single server can't handle, heavy database queries running repeatedly on every request, and static files (images, scripts, stylesheets) being regenerated from the server each time. On normal days these issues go unnoticed because the server coasts on idle capacity. When campaign-day traffic jumps 10-20x, that same capacity is no longer enough and the system gets buried under a queue of requests.

The solution isn't buying one "big server." The real fix is distributing the load across the right layers and letting each layer do its job as efficiently as possible. The four layers below form the backbone of that distribution.

CDN: move traffic to the edge, not the origin

A content delivery network (CDN) serves static assets — your images, scripts, and stylesheets — from the server geographically closest to the user. This means your origin server doesn't have to send the same file over and over on every request; it only has to deal with content that's actually dynamic and changing.

• The vast majority of static assets (images, CSS, JS) should be served via a CDN, from the point closest to the user,
• Product images should be pre-optimized and generated for different screen sizes ahead of time,
• CDN cache durations should be tuned to how often content changes — long for files that rarely change, short for those that change often.

A CDN's payoff isn't just speed; by significantly reducing the load on your origin server, it frees up that capacity for what actually matters — creating orders, checking stock, processing payments. On campaign day, this separation is one of the most decisive factors in whether your site stays up. We covered the impact of CDNs on speed in the context of Core Web Vitals in a separate article.

Caching layers: page, query, and object

A CDN handles static files, but dynamic pages (product listings, category pages, search results) don't need to hit the database on every single visit. Caching means computing a result once and reusing it for a set period; on campaign day, when thousands of people view the same product page, sharing a single computed result instead of hitting the database thousands of times is what saves your server.

• Page cache: Pages that rarely change (category, campaign, static content) can be cached as full pages for a few minutes,
• Query cache: Data that's read often but written rarely, like stock and price, is kept in an in-memory caching layer (e.g. Redis),
• Object cache: Structures that are expensive to compute but rarely change, like menus or category trees, are cached and cleared when something actually changes.

The hardest part of caching is deciding when to refresh it. For data that requires real-time accuracy, like stock levels, cache duration should be kept very short, or the cache should be invalidated instantly when stock changes; otherwise, a product that's sold out can keep showing "in stock" in the cache.

Horizontal scaling: growing server count with demand

Vertical scaling means growing a single server with more powerful hardware; past a certain point it becomes unsustainable, both in cost and physical limits. Horizontal scaling means bringing multiple servers online to do the same job and distributing incoming traffic across them through a load balancer.

The strength of this model lies in its flexibility: two or three servers may be enough on a normal day, but that number can be scaled up to ten, automatically or manually, ahead of a campaign, then scaled back down once it's over. For horizontal scaling to work, the application needs to be designed "stateless" — meaning user session or cart data isn't stored in a single server's memory, but in a shared layer (a database or Redis) that all servers can access. Otherwise, when a user's requests land on different servers, their cart can appear to have "disappeared."

To make clear when each approach is the right choice, it helps to put the key differences side by side:

"Campaign day isn't the day you test your infrastructure — it's the day your infrastructure tests you. Preparation starts weeks before the day arrives."

The database bottleneck: the most commonly overlooked point

Adding more servers is easy; the real bottleneck usually piles up in a single database. Since all servers read from and write to the same database, load on the database grows as server count grows, and at some point the database becomes the weakest link in the whole architecture.

Three measures help here: reading data that's read often but changes rarely from a cache instead of the database, serving read-heavy queries through a "read replica" separate from the primary database, and queuing critical, concurrency-sensitive operations like stock deduction so the database isn't hit with thousands of simultaneous write requests. Queuing is one of the most effective ways to smooth out sudden load spikes, especially at moments like "add to cart" and "place order."

Load testing before a campaign

No matter how well the architecture is designed, going into campaign day without testing it against real traffic is risky. Load testing lets you find your site's breaking point in advance, using tools that simulate several times the expected visitor count.

1. Build a scenario targeting 2-3 times the expected peak traffic, based on your past campaign data,
2. Don't just test the homepage — include the product page, cart, and checkout flow, since the real bottleneck usually shows up at checkout,
3. Run the test at least a week before the campaign, so you have time to fix any issues found and retest.

Estimating expected traffic requires the same kind of planning discipline on the inventory side; we covered pre-season demand forecasting in detail in our demand forecasting guide.

Real-time monitoring and automatic alerts

The most dangerous scenario on campaign day is a problem growing unnoticed. Set up a dashboard that monitors indicators like server response time, error rate, and queue length in real time, so your team gets an automatic notification when set thresholds are crossed. Defining a rule that automatically triggers horizontal scaling based on traffic also grows capacity without waiting for the team to intervene manually.

Another benefit of monitoring is post-campaign evaluation: data on when the peak occurred, which page drove the most load, and how much of your available capacity was used makes planning for the next campaign far more accurate.

Conclusion

Staying up under high traffic isn't about buying one powerful server — it's about an architecture that distributes load across the right layers (CDN, cache, application servers, database) and can grow and shrink with demand. Testing this architecture before campaign day lets you fix problems before customers ever notice. To plan your campaign calendar together with this infrastructure preparation, take a look at our Black Friday readiness guide.

Building this infrastructure from scratch is an engineering effort that requires the right team and time. Şimşek Software's e-commerce platform ships with CDN integration, multi-layer caching, and a server architecture that scales with demand out of the box — so you can focus on sales instead of infrastructure worries on campaign day.