"Make it faster" is one of the least actionable instructions in engineering, right up until you have data telling you exactly where the time is going. Over about two and a half years on a high-traffic e-commerce platform, we reduced platform latency by roughly 30% while maintaining 99.9% uptime during peak trading periods — including the highest-traffic days of the year, when the margin for error is smallest, and the cost of getting it wrong is highest. None of it came from a single dramatic rewrite. It came from a repeatable process, applied consistently.
Start by refusing to guess
The instinct when something feels slow is to optimise the thing you assume is slow — usually whatever you last touched, or whatever looks inefficient on a quick read. That instinct is wrong often enough to be actively dangerous, because "optimising" code that wasn't the bottleneck adds complexity and risk for zero latency benefit, and it burns the time you should have spent on the actual bottleneck.
The fix is boring and non-negotiable: profile first, in an environment that resembles production traffic patterns, before writing a single optimisation. Real bottlenecks are frequently unglamorous — an N+1 query hiding behind an ORM abstraction, a synchronous call to a downstream service that could have been parallelised, a cache that's technically present but missing on the hot path that actually matters.
Where the 30% actually came from
Roughly, the wins broke down into three categories:
Query optimisation. The single highest-leverage category. Several code paths were making sequential database round-trips with no data dependencies between them — classic N+1 patterns introduced incrementally as features were added over time, none individually alarming, collectively expensive. Batching these, and in a few cases denormalising specific hot-path reads, produced the largest single latency improvements we measured.
Targeted refactoring of performance-critical paths. Not a rewrite — a refactor scoped specifically to the paths the profiler flagged. This mattered for maintainability as much as speed: refactoring only what the data justified meant the team could reason about why each change existed, instead of inheriting a large diff whose performance rationale had to be taken on faith.
Infrastructure-level tuning. Some latency wasn't in application code at all. Right-sizing EC2 instances and Lambda configurations for actual observed load, rather than defaults inherited from an earlier stage of the business, closed gaps that no amount of query optimisation would have touched.
The part that's easy to skip: measuring in production, safely
A profiler on a laptop tells you about your laptop. Production traffic has a shape — concurrency patterns, cache warmth, data skew — that's genuinely hard to fake in staging. The way to close that gap without risking the platform is incremental rollout with real metrics at every step:
1. Ship the change behind a flag or to a small traffic percentage
2. Compare p50/p95/p99 latency against the control group, not just the mean
3. Watch error rate and downstream load, not just the metric you're optimising
4. Roll forward only when the data says so — not the calendar
The p95/p99 discipline matters specifically because averages hide the experience of your worst-off users, and in e-commerce, the worst-off users during peak trading are disproportionately the ones checking out at the exact moment load is highest — which is to say, the moment you can least afford to be wrong.
Automation as a latency and reliability strategy
Alongside the latency work, we built internal automation that cut manual data processing by 80%. That's not directly a latency number, but it's related: manual processes are a hidden source of both delay and error, and every manual step you remove is one less place where a human under time pressure introduces a mistake during exactly the high-traffic periods when mistakes are costliest. Reliability and performance work end up reinforcing each other more than people expect.
What held up across the whole effort
- Profile before you touch anything. Every optimisation that didn't start here either did nothing measurable or made something else worse.
- Optimize what the data flags, not what looks inefficient. These are not the same list, and the gap between them is where wasted effort lives.
- Measure tail latency, not averages. Peak-trading experience is a p99 problem, not a p50 problem.
- Ship incrementally, with rollback as a real option, not a theoretical one. 99.9% uptime through peak periods isn't compatible with big-bang deploys.
The unglamorous truth is that most of the 30% came from patient, boring, well-measured work — not a single clever trick. That's usually how sustainable performance work goes, and it's the part that's easy to leave out of the story.
Top comments (0)