Designing for availability, growth and a low-risk migration
A server with dual PSUs, RAID 10 and hot-swap drives still fails as one unit if its motherboard, RAID controller, operating system or rack network fails. Feed each PSU from a separate power circuit, monitor disk health, checkout latency and error rates every 60 seconds, and alert an on-call engineer after two failed checks.
| Business tolerance | Suitable design | Replication outcome |
|---|---|---|
| Up to 4 hours offline | One server plus encrypted off-site backups | Recovery follows the backup RPO |
| Under 15 minutes offline | Two servers behind a load balancer, with database replication | Asynchronous lag below 60 seconds means failover can lose up to 60 seconds of confirmed orders |
| No committed-transaction loss after one site fails | Two sites with synchronous database replication | Zero committed-transaction loss, provided one replica and quorum remain available |
Synchronous replication is not automatically the right choice. A London to Frankfurt link budgeted at 20-40 ms per synchronous database round trip can add that delay to each checkout write; measure it with the application before committing to the design.
- Keep encrypted copies in a second region, with 30 daily and 12 monthly restore points. Set an RPO such as 15 minutes and an RTO such as 2 hours, then test a full restore every quarter.
- Retain 30% CPU and memory headroom for seasonal peaks. Add a server when peak CPU exceeds 70% for 15 minutes, separate the database when storage latency exceeds 10 ms, and consider hybrid cloud bursting if a four-hour promotion exceeds installed capacity.
- Before migration, benchmark peak requests per second and p95 checkout time, inventory payment callbacks, cron jobs and IP allowlists, lower DNS TTL to 300 seconds at least 48 hours ahead, synchronise changing data, and rehearse one cutover.
- Migrate during the lowest recorded traffic hour. Run both environments for 24 hours where licensing permits, with a rollback trigger such as payment failures above 1%.
After cutover, test payments, stock, orders, email, search, analytics, shipping integrations, scheduled jobs and third-party allowlists. Require provider commitments in writing, including a 15-minute critical-response target, a four-hour hardware-replacement target, 24/7 monitoring, named managed-service boundaries and DDoS coverage stated in Gbps and packets per second.
How to size a dedicated server for e-commerce workloads
Size from the busiest 15-minute interval, not monthly visits. Record concurrent users, requests per second, CPU utilisation, available RAM, p95 database latency and storage IOPS. Keep CPU below 70%, RAM below 80% and p95 database queries below 100ms during the test.
| Workload | Starting point | What to verify |
|---|---|---|
| WooCommerce, 10,000 products | 8 fast cores, 32GB RAM | 100 concurrent users, 40-80 requests/s |
| Magento, 100,000 SKUs | 16 cores, 64GB RAM | 24GB MySQL buffer pool, 12GB OpenSearch heap, p95 search below 200ms |
Choose higher clock speed when PHP request execution limits throughput: eight 3.8GHz cores can beat sixteen 2.4GHz cores if each request depends mainly on one core. Choose more cores when imports, indexing, queue consumers and checkout traffic overlap. A 500ms payment or stock API call holds a worker ten times longer than a 50ms call; at 20 checkouts/s, that difference raises concurrent worker demand from about 1 to 10 before retries.
Reserve 4-8GB for the operating system and monitoring, then allocate memory explicitly to PHP workers, MySQL, OpenSearch and Redis. Leave 20% unallocated for spikes. Extensions and catalogue indexes can change these figures, so treat them as test baselines.
- Use NVMe rated for at least 1 drive write per day, sub-1ms p95 latency and 50,000 sustained random-write IOPS.
- Use RAID 1 for two drives or RAID 10 for four or more. RAID is not a backup; retain an off-server copy.
- Calculate peak throughput from page weight and uncached requests. A 3MB page at 20 views/s is 480Mbps. With 10% protocol overhead, 50Mbps uploads and a 60% utilisation ceiling, a 1Gbps port is tight unless a CDN offloads at least 40%.
Load-test browsing, basket changes, checkout, imports and administration together for 30-60 minutes, then size for the measured peak plus 30% capacity.
Optimising performance for traffic spikes and fast checkouts
Tune the web server, runtime and database against a repeatable load test. Define measured concurrency as the highest test level sustained for 15 minutes with fewer than 1% HTTP errors and checkout p95 below 800 ms. If 40 concurrent checkouts produce 100 requests per second, test the campaign target at 120%: 48 checkouts and 120 requests per second.
| Layer | Measurable rule |
|---|---|
| Runtime workers | Divide RAM available to the runtime by measured memory per worker. With 8 GB available and 160 MB workers, the theoretical limit is 51; cap it near 40 to retain about 20% headroom. |
| Database | Log queries over 200 ms, inspect those repeated during checkout, and add indexes only after confirming execution plans. |
| Caching | Cache anonymous catalogue pages for 60-300 seconds, objects and query results for 30-120 seconds, and compiled opcode until deployment. |
Never cache baskets, account pages, live inventory or payment responses. Shopper-specific recommendations or recently viewed products may be cached for 5-15 minutes only with a per-shopper key and deletion on logout.
Put cacheable images, scripts and styles behind a CDN with versioned URLs and a 30-day browser lifetime. Convert suitable photographs to WebP or AVIF, target 100-200 KB per product image, and enable Brotli or gzip for text assets. Use HTTP/2 for shoppers on current browsers; retain HTTP/1.1 only for a named legacy case such as Internet Explorer 11 on Windows 7. These changes reduce origin requests, but inefficient application code still needs profiling.
Separate web, application, database, search and background workers when any workload consumes over 70% of its allocated CPU or RAM for 15 minutes. If one server then limits capacity or creates a single failure point, place two or more stateless application servers behind a load balancer. Track real-user p75 Largest Contentful Paint below 2.5 seconds alongside CPU, memory, query latency and queue depth, then use the 120% test result to approve or increase campaign capacity.
When does a high-traffic e-commerce site need dedicated hosting?
Dedicated hosting is single-tenant physical infrastructure: one site has exclusive access to the server's CPU, memory, storage and network capacity.
| Platform | Typical allocation and trade-off |
|---|---|
| Shared | Often 1-2 CPU cores, 1-4 GB RAM and process limits set by the provider; little server control. |
| VPS | Usually 2-16 vCPUs and 4-64 GB RAM with isolation from neighbouring virtual machines; resizing commonly requires a reboot lasting 1-10 minutes. |
| Cloud | Instances can be added in 2-10 minutes and billed per second or hour, but load balancing, replicated databases and failover add operational work. |
| Dedicated | A 16-core, 128 GB RAM server may cost about £250-£600 per month on a fixed term; hardware changes can take hours or require migration. |
Investigate migration when checkout p95 latency exceeds 2 seconds, CPU remains above 70-80% for 15 minutes, memory exceeds 85%, database lock waits pass 200 ms, or 503 errors recur during campaigns. Consistent demand means those levels persist for roughly 30 or more hours each week. Database contention, resource-limit errors and repeated outages are stronger signals than monthly visits alone.
A catalogue with 500,000 products, 2,000 concurrent sessions, personalised pricing and several payment or stock integrations can need more capacity than a cached store receiving greater traffic. Dedicated hardware suits steady workloads where reserved capacity keeps checkout available and the monthly bill near the contracted £250-£600 range. For a campaign that raises demand fivefold for six hours, elastic cloud or a hybrid design is usually safer. Buying hardware for the campaign peak can leave 60-80% of its capacity idle for the rest of the month.
Security, PCI DSS and DDoS protection responsibilities
Bare metal has no customer-facing hypervisor layer, but provider management systems, upstream networks and control panels remain shared dependencies. PCI DSS 4.0.1 compliance still depends on configured controls and documented evidence.
| Control | Example implementation | Typical owner |
|---|---|---|
| Host security | Run a supported OS; install critical OS patches within 7 days; use anti-malware and file-integrity monitoring; retain audit logs for 12 months, with the latest 3 months immediately available. | Customer on unmanaged hosting; provider if listed in a managed contract |
| Access | Require MFA, named administrator accounts and least privilege. Permit TCP 443 publicly, but restrict TCP 22 to a corporate VPN such as 203.0.113.0/24. Review access every 90 days. | Shared |
| Data | Use TLS 1.2 or 1.3 in transit and AES-256 disk or database encryption at rest. Store credentials in a secrets manager, rotate privileged secrets every 90 days, and place card-data systems in a separate VLAN. | Customer application team |
| Testing | Run external vulnerability scans every 3 months and after installing a payment module or changing firewall rules. Conduct penetration testing at least annually and after either change. | Customer and approved testing provider |
A Stripe Checkout redirect, where card fields never touch the merchant server, may qualify for SAQ A; the merchant must confirm eligibility, check Stripe's PCI DSS attestation and record each shared responsibility.
Size DDoS controls against a scenario, such as 20 Gbit/s of network traffic plus 100,000 HTTP requests per second. Upstream filtering might absorb 50 Gbit/s, while a WAF limits login attempts to 10 per minute per IP and a CDN caches product images for 1 hour. A common mistake is leaving the origin IP reachable: allow TCP 443 only from the CDN's published CIDRs.
An incident plan should name a 15-minute escalation contact and require credential revocation within 30 minutes. A managed contract might promise emergency firewall changes within 30 minutes; unmanaged hosting leaves that action, application patches and incident containment with the customer.
