Retail & e-commerce
Commerce platforms that hold up on the busiest day of the year
Retail engineering is judged on a handful of hours a year. A platform that is comfortable in November can still fall over on Cyber Monday, and the cost of that failure is measured in lost carts, not in downtime minutes.
What the work is up against
01
Peak load is the only load that counts
Traffic during a sale event routinely runs ten times a normal day. Infrastructure sized for the average is infrastructure that fails when revenue is highest.
02
Latency is conversion
Mobile shoppers abandon long before a page times out. Sub-second response is a commercial requirement, not a performance nicety.
03
Legacy monoliths cannot be scaled selectively
When checkout and catalogue share a deployment, a spike in browsing takes payments down with it.
What we build for retail teams
Headless commerce architecture
Cloud-native builds on Azure or AWS that separate the storefront from the commerce engine, so the presentation layer can be rewritten without touching order processing.
Independent scaling of checkout
Microservice decomposition so a browsing spike cannot take payments down with it. Checkout gets its own capacity envelope and its own failure domain.
Edge caching and database sharding
Caching tuned to the read patterns of an event day, and sharding that keeps write contention off the critical path when order volume multiplies.
Next.js storefronts built for Core Web Vitals
Server rendering, disciplined image handling and reserved layout space, because retail LCP and CLS are measured on mid-range phones over mobile networks.
Load-testing against modelled peak profiles
Rehearsing the event before the event, against a traffic profile derived from last year rather than a flat synthetic ramp.
How we approach it
Start from the event, not the average
Capacity planning that begins with a normal Tuesday will always undershoot. We model the peak first and work backwards, which usually reveals that the constraint is not raw compute but a handful of synchronous calls on the checkout path.
Decompose along failure lines
Services are split by what needs to survive independently rather than by team structure. For Lider that meant catalogue, cart and payment becoming separately deployable — so the heaviest traffic, which is browsing, could never reach the part of the system that takes money.
Measure conversion, not uptime
A platform can be green on every infrastructure dashboard and still be losing carts to a slow mobile render. The metrics that governed the Lider work were page load time and mobile conversion, which is why a 65% latency reduction showed up as a 40% conversion lift.
Delivered work
Lider — Walmart Chile
Chile’s leading retail hypermarket, re-architected from a legacy monolith to headless microservices ahead of its largest sales event.
- Monthly users at peak
- 10M+Monthly users at peak
- Uptime through Cyber Monday
- 99.99%Uptime through Cyber Monday
- Reduction in page load time
- 65%Reduction in page load time
- Increase in mobile conversion
- 40%Increase in mobile conversion
Questions we get from retail teams
- How far ahead of a peak event should we start?
- Twelve weeks is the realistic minimum for architectural work, because the load-testing cycle alone needs several weeks to be meaningful. Optimisation inside an existing architecture can be done in four to six. Anything shorter than that becomes risk mitigation rather than engineering — worth doing, but do not expect a structural change to land safely.
- Do you rebuild the platform or optimise what exists?
- Usually neither in full. The common pattern is selective decomposition: identify the two or three services that cannot be allowed to fail together, separate those, and leave the rest alone. A complete rebuild is rarely justified and almost never fits the calendar between one peak event and the next.
- Can you work with our existing commerce engine?
- Yes. Headless architecture exists precisely so the storefront and the commerce engine can evolve independently. We have taken this route on platforms running on established commerce backends where replacing the engine was neither desirable nor affordable.
- What do you need from our team?
- Access to real traffic data from previous peak events, someone who understands the existing order flow, and a decision-maker for trade-offs during the load-testing phase. Modelling peak load from synthetic assumptions rather than last year’s actual profile is the single most common reason this work underdelivers.