Case Study: Faster and Cheaper
The situation. The client’s delivery fleet was hitting capacity during peaks — slowdowns, strained servers, an ops system working overtime to keep things smooth. The conventional answer is reflexive: add servers, grow the bill.
The investigation. Before buying anything, we measured what the fleet actually starved for. The answer was lopsided: servers were compute-bound with 84% of their (expensive) memory sitting idle — the wrong machine shape for the workload — and on shared-CPU instances whose performance wobbled with noisy neighbors at exactly the busy moments that mattered. We also found a compounding factor most sizing exercises miss: every additional server dilutes the caches. Content edits must re-render once per server, so more small servers means colder caches and more slow first-loads — the naive “just add nodes” plan would have partially defeated itself.
The solution. A live A/B, not a leap: we cloned a production server onto a dedicated-CPU tier — cheaper per node than the incumbent — admitted it to the load balancer as a low-weight canary, graduated it to a full traffic share, and measured it against its siblings under real load for days. It matched the fleet on throughput, beat it on consistency, and did it for less money. The data settled the target architecture: fewer, stronger servers — 50% more total compute, all dedicated, with fewer caches to keep warm — and the migration executed live, node by node, with zero downtime and zero errors recorded through every transition. The worst-performing legacy server (14 days of health telemetry made the choice for us) was retired the same week.
Results.
- ~50% more real compute than the original fleet, with noisy-neighbor variance eliminated
- Warmer caches by construction — every content edit now re-renders on fewer machines
- Monthly infrastructure cost lower than the fleet it replaced
- Every step validated live behind a load balancer: no downtime, no maintenance window, no leap of faith