E-commerce Scale-up
An online retailer had outgrown the setup that launched the business. Ordinary weeks were fine; sale days were not. The previous two holiday peaks had both ended in checkout failures at exactly the moment the traffic was worth the most. We rebuilt the infrastructure to absorb those spikes, and to cost sensibly on the ordinary days in between.
- Sector
- Direct-to-consumer retail
- Engagement
- Infrastructure rebuild and performance engineering
- Timeline
- 5 months, completed ahead of the festive season
The challenge
- Fixed-capacity servers were sized for average traffic. A sale pushed load ten times higher within minutes, and nothing scaled to meet it.
- The catalogue was rendered on demand on every request, so the pages that drew the most traffic were also the most expensive to serve.
- Checkout shared a database connection pool with catalogue browsing. Under load, shoppers browsing starved the pool and paying customers were the ones who saw errors.
- Inventory counts were read straight from the primary database, making the single busiest query also the single biggest point of contention.
- There was no load testing. Capacity was a guess, confirmed or refuted by whatever happened on the day.
Our approach
Each step below was finished and verified before the next one started, so the risk stayed contained at every stage.
Reproduce the failure before fixing it
We built a load-test harness that replayed the previous peak's real traffic shape against a staging copy. That made the failure reproducible on a Tuesday afternoon instead of once a year, and it became the gate every later change had to pass.
Separate the paths that must not fail
Checkout and payment were given their own service boundary, their own connection pool and their own scaling rules. Browsing traffic can now surge as much as it likes without ever taking capacity away from a customer who is paying.
Serve the catalogue from the edge
Product and category pages moved to statically generated pages revalidated on content change and served from a CDN. The pages carrying the heaviest traffic stopped touching the application servers at all.
Make inventory reads cheap
Stock levels moved to a cache updated by order and restock events, with the authoritative check kept where it matters — at the point of order placement. Browsing shows accurate stock without hammering the primary database.
Scale on demand, shrink afterwards
The application runs on an orchestrated cluster that adds capacity on queue depth and request latency, then releases it when the spike passes. Peak capacity stopped being something the client pays for year-round.
What we delivered
- An isolated checkout and payment service with dedicated capacity
- Statically generated, CDN-cached catalogue and category pages
- Event-driven inventory cache with authoritative checks at order time
- Autoscaling cluster configuration tuned against replayed peak traffic
- A repeatable load-test suite the client runs before every sale
- Dashboards and alerts covering checkout success rate, not just uptime
Technology used
- Next.js
- Node.js
- PostgreSQL
- Redis
- Kubernetes
- CDN edge caching
The results
10x
Peak traffic absorbed
The festive peak ran at roughly ten times baseline load with no checkout failures and no manual intervention.
Faster
Catalogue page loads
Product and category pages now come from the CDN, so they load at the same speed on a sale day as on a quiet one.
Lower
Off-peak infrastructure cost
Capacity is released once a spike passes, so the client no longer pays all year for servers sized for one week.
Rehearsed
Every sale, in advance
Peak load is now replayed against staging before each event, so capacity is a tested number rather than an estimate.
The retailer went through its next two peak seasons without an incident call. The more useful change was cultural: capacity is now something the team verifies in advance rather than discovers on the day.
Have a similar problem?
Tell us what is slowing you down and we will tell you honestly whether it needs a rebuild or a much smaller fix.