Network design for e-commerce and retail
Retail networks fail in two different places, and they need different work. One is the path between a customer and your site. The other is the path between a store and everything it depends on. Optimising the first while the second is the problem is the most common wasted quarter in this sector.
The floor physics puts under your page speed
Before any tuning, there is a limit set by distance alone.
A page needs several round trips before content arrives — DNS, the TCP handshake, the TLS negotiation, then the request itself. Four round trips to a server in New York from a customer in Mumbai is half a second spent before a single byte of the page is delivered, and no amount of image compression touches it.
Which is why the answer to a slow site for distant customers is to shorten the distance: serve static assets from edge locations near the customer, terminate TLS at the edge so the handshake is local, and keep the number of round trips low by consolidating requests. Moving the origin closer to the largest market helps the requests that must reach it.
The store side, which is usually the real problem
A store that cannot take payment is closed, whatever the website is doing. Three things decide whether that happens:
A second path, on a different medium
Two fibre links from the same provider down the same duct are one link with extra billing. A genuine second path means different last-mile infrastructure — commonly a cellular backup, which is more than adequate for card authorisation traffic even though it would not carry the whole store.
Failover that has been watched happening
Automatic failover that nobody has tested is a configuration, not a capability. Test it by pulling the primary during trading hours once, with the team ready, rather than discovering the behaviour on a Saturday.
Knowing which traffic matters
On a constrained link, payment authorisation, stock lookup and the till competing with software updates and store Wi-Fi will lose unless something says otherwise. Prioritisation is a one-time configuration that pays for itself the first time a link degrades rather than fails.
What to measure
- Time to first byte from your customers’ locations, not from your office. The office is usually close to the origin and tells you nothing.
- Failover time per store, recorded from an actual test.
- Packet loss on the store links, which degrades a till long before an outage would show on an uptime graph. See diagnosing loss, latency and jitter for how to read those numbers.
Where this fits
The service is Network Solutions, and the sector context is E-commerce and Retail. Peak-season capacity is an architecture question — see Cloud Architecture and Design — and ongoing monitoring of the store estate is Infrastructure Managed Services.
