E-Commerce Hosting in the Cloud

Storefront traffic has an awkward shape

A shop is not a steady workload. It idles for weeks, then triples in a morning because a newsletter went out, and quadruples again for four days in late November. The infrastructure has to be sized for the peak but paid for during the trough.

The second awkward property is that the expensive requests and the valuable requests are different. Product listings are cacheable and cheap; cart, checkout and account pages are personal, uncacheable and the ones that actually earn money. Everything in a good store architecture follows from that split.

The third is that failure is immediately measurable. A slow checkout does not generate a support ticket, it generates an abandoned basket, which is why store infrastructure is judged on latency and conversion rather than on uptime alone.

Self-hosted or hosted platform

Before the infrastructure question comes the platform question. A hosted commerce service removes the server problem entirely and charges a share of revenue for doing so. A self-hosted platform such as WooCommerce, Magento Open Source, PrestaShop or a custom application gives you control of the data, the checkout flow and the integrations, and hands you the operational burden.

The honest decision rule is about customisation, not cost. If your catalogue, pricing logic or fulfilment integrations are ordinary, a hosted platform is usually the better business decision. If they are the thing that differentiates you, self-hosting is worth the operations work.

There is a middle route worth knowing about. Several teams run a hosted checkout and payment layer behind a storefront they control, which keeps the sensitive flow with a specialist while the catalogue, content and campaign pages stay in their own codebase. It splits the operational burden roughly along the line between the cacheable and the transactional.

The rest of this article assumes self-hosted, because that is where the cloud architecture decisions live. Most of it applies to the middle route as well, minus the checkout specifics.

The layers of a cloud storefront

Notice how much of the design exists to keep the application tier stateless. Once carts and sessions live outside the instances, you can replace, scale or patch them without logging anyone out.

Caching without breaking the basket

Caching is where store performance is won and where store bugs are born. The rule is simple to state and easy to get wrong: cache aggressively for anonymous visitors, never for authenticated ones or anyone with a populated cart.

Implement that with explicit rules rather than by accident. Exclude the checkout and account paths at the CDN, honour the platform's own cache-control headers, and make sure the session cookie is respected as a cache key. A page cache that serves one shopper's basket to another is the failure nobody forgets.

Below the page cache, use an object cache in Redis for database query results and rendered fragments. That is where most of the improvement in time to first byte comes from on a catalogue-heavy store.

Images deserve their own attention. Serve resized variants rather than full-resolution originals, use modern formats where the browser accepts them, and let the CDN handle delivery. Our guide to CDN basics for cloud-hosted sites covers the configuration patterns.

Preparing for a peak event

A sale day is a scheduled incident, and it should be rehearsed like one. The work happens in the weeks before, not on the morning itself.

1. Load test against a staging copy with production-shaped data, and find the layer that breaks first. It is usually the database or the search index, rarely the web tier.
2. Scale up in advance rather than relying on reactive autoscaling, which takes minutes your sale does not have. Scheduled scaling is the right tool here, as described in autoscaling explained.
3. Raise the capacity of the database and cache tiers too. A web tier scaled alone simply queues faster at the bottleneck.
4. Freeze deployments for the window, and agree in advance which features can be switched off to shed load.
5. Watch order completion rate, not just server metrics. It is the only number that tells you whether the shop is working.

Payments, compliance and webhooks

Keep card data out of your infrastructure. Redirecting to the payment provider's hosted page, or embedding their tokenising fields, keeps the sensitive fields off your servers entirely and dramatically reduces the compliance scope you have to evidence. The general framework for cloud obligations is outlined in cloud compliance basics.

Webhooks from the payment gateway are the part teams underestimate. They arrive out of order, they retry, and they occasionally arrive twice. Make the handler idempotent, keyed on the provider's event identifier, and store the raw payload before processing it so a bug can be replayed rather than reconstructed.

Many gateways also send from a fixed set of source addresses. Record which of your firewall rules depend on that, because it is exactly the detail that breaks when infrastructure moves.

Finally, treat the order database as the system of record and back it up accordingly, with point-in-time recovery enabled rather than nightly dumps alone. Losing four hours of orders is not a technical incident, it is a set of customers who paid for something you cannot see, and reconstructing that from gateway records is slow and error prone.

Refunds, chargebacks and partial fulfilment all write to the same records, which is another argument for a single authoritative order store rather than state spread across the shop, the warehouse system and a spreadsheet.

Key takeaways

• Design around the split between cacheable catalogue traffic and uncacheable checkout traffic.
• Push sessions and carts out of the application instances so the tier stays disposable.
• Exclude cart, checkout and account paths from edge caching with explicit rules, not by hope.
• Scale the database, cache and search tiers before a sale, on a schedule, not reactively.
• Keep card data off your servers and make gateway webhook handling idempotent.
• Measure order completion rate during peaks; infrastructure metrics alone will not tell you the shop is broken.

For hosting choices, a hyperscaler suits stores with complex integrations while a developer cloud suits most mid-sized shops; the contrast is drawn in the AWS and DigitalOcean comparison, and the AWS account listings describe the managed services a larger storefront tends to reach for. AWS documents caching behaviour in the CloudFront developer guide, and Redis persistence options are described in the Redis persistence documentation.