No traffic limits: what edge caching does for a small store

What happens when a customer clicks a link

Without jargon: the customer clicks, their browser asks the server "give me this page", and the server has to build it - fetch the product from the database, check stock, apply the promotion, render the HTML - and only then send it back. That is SSR, server-side rendering.

With five customers, the server does this five times and nobody notices. With five thousand at once, because someone posted your product on TikTok, the server builds the same page five thousand times - and at some point it can't keep up. The page starts loading in a second, then three, then not at all.

Caching: build the page once, serve it to many

Caching turns that logic around. Instead of building the same page on every visit, we build it once and keep the finished version. The next customers get the stored copy - without touching the database, without recalculating anything.

For the customer the difference is immediate: the page appears at once instead of after a second of the server "thinking". For you, the difference is that five thousand visits do not make the server do the same work five thousand times.

Only what is the same for everyone can be stored: a product page, a category, the home page seen by an anonymous visitor. Checkout and a logged-in customer's pages are always built fresh, because they belong to that customer alone.

"The edge", or closer to the customer

The second element is where that finished page lives. The store's server sits in one place - if the customer is far away, the data has to travel that distance, both ways.

The edge means the finished page sits at the edge of the network, in a data centre close to the customer. Stores on DoSwiftly run on the Cloudflare network: a page built for the first customer lands in the memory of the data centre they came through (the store's code decides which pages may be stored this way), and the next customers from that area get it from there instead of waiting for the server. To be fair: each data centre has its own memory, so the gain grows with traffic. With a handful of visits a day little changes - during a viral spike, when thousands of people open the same page, it works hardest. And that moment is what this article is about.

Freshness: how the cache knows the price has changed

The natural question: if the page is stored, what happens when I change a price or a product goes out of stock? Will the customer see the old version?

For a moment - yes, and it is worth knowing. A stored page has a short shelf life: on DoSwiftly, a finished page at the network edge lives for two minutes at most. A price change in the admin panel immediately invalidates the product data on the platform side, and the finished page refreshes once its time is up. In practice, for a minute or two after the change some customers may still see the previous price on the product page.

It is a deliberate trade-off: without that window every customer would rebuild the page from scratch and during a viral spike we would be back to square one. If your store runs on Next.js, ISR (Incremental Static Regeneration) works in a similar way: a page stored on the server refreshes in the background once the time set in the store's code has passed - the customer does not wait for the render, and the content catches up with changes shortly after.

Why this is not a "big players only" problem

A big store has steady, predictable traffic and an infrastructure budget. A small store has something worse: unpredictable traffic. An influencer's post, a media mention, a well-aimed campaign - and overnight ten times more people show up than usual.

That is exactly the moment your store cannot go down. Not because you would lose one day of sales - because you would lose the one chance when that many people were looking at you.

What we don't do

Let's say it plainly: we do not limit traffic on any plan. A sale, a campaign or a viral hit does not trigger surcharges or switch on a page-view meter - you pay for paid orders, not for visits. Every plan runs on the same infrastructure with the same caching: the plan changes neither how fast your store is nor how many people can come in. The only limits are protections against bots and abuse - the same for every store.

Because a traffic limit in e-commerce is a construction that punishes you for exactly what you want most: success.

See how store hosting works on DoSwiftly.