# Optimizing Safely in Production Your benchmark says the change is faster. That's a good sign and it is not the finish line, because a benchmark is a controlled, simplified, optimistic version of reality. Production has cold caches, noisy neighbors, weird data, traffic spikes, and a long tail of slow requests your benchmark never generated. The change that's faster on your laptop can be neutral - or worse - under real load. So the mental model for this final phase is: **a benchmark result is a hypothesis about production, and production is the only judge.** Verifying there, with real traffic, watching the right numbers, is what turns "looks faster" into "is faster." We'll close with a few traps that can make even a real, measured speedup not worth what you paid for it. ## Verify with real traffic and observability **What it actually is.** Verifying in production means watching your live system's performance metrics *before and after* the change ships, on real user traffic - using the observability you already have (or should). The benchmark proved the change *can* help; the production metric proves it *does*. **Why benchmarks lie by omission.** A benchmark runs one workload, usually warm and uniform. Production runs every workload at once: the user with ten items and the one with ten thousand, the cache-cold first request after a deploy, the request that hits the one overloaded shard. Your optimization might help the common case and hurt a rare-but-important one - only production traffic exercises all of it. **What it does in real life.** You ship behind a flag or to a fraction of traffic, then watch the same metric you targeted in [Phase 1](01-the-optimization-loop.md) move on the live dashboard. ```console $ # checkout p95 latency, before vs after the index change rolled out 14:00 p95 1180ms ← before 14:05 p95 1205ms 14:10 p95 270ms ← change reaches 100% of traffic 14:15 p95 265ms ``` *What just happened:* The live metric confirms what the benchmark predicted - p95 dropped to ~270ms under real traffic, matching the target. Now it's a result, not a hope. If the line *hadn't* dropped, you'd have learned your benchmark wasn't representative - worth knowing before declaring victory. Standing up the metrics and traces that make this visible is the subject of [Observability: Logs, Metrics, Traces](/guides/observability-logs-metrics-traces). ⚠️ **Gotcha - ship it observably, not blindly.** Rolling a performance change to 100% of traffic with no way to compare before/after and no quick rollback is how a "speedup" becomes an incident. Use a feature flag, a canary, or a staged rollout so you can see the effect on a slice first and back out fast if it regresses something. ## Watch percentiles, not averages This is the single most important measurement idea in production performance, and it's where averages quietly betray you. 📝 **Terminology.** A *percentile* describes the slow end of your distribution. *p95 latency* is the value that 95% of requests come in under (so the slowest 5% are above it); *p99* is the value 99% beat. *Tail latency* is shorthand for these high percentiles - the experience of your unluckiest requests. **Why the average is a trap.** An average smears all your requests into one number and hides the slow tail completely. A system can have a beautiful average and still be making a meaningful fraction of users miserable. ```text 1000 requests, two ways to describe them: AVERAGE: ~110ms ← looks great, ship it! reality: 950 requests → 50ms (fast, the happy majority) 50 requests → 1200ms (the slow tail - 1 in 20 users) p50 = 50ms ← the typical request p95 = 1200ms ← what 1 user in 20 actually feels ``` *What just happened:* The average (~110ms) makes the system look healthy while 1 in 20 requests takes over a second. The percentiles tell the truth: the typical user is fine (p50 = 50ms) but the tail is bad (p95 = 1200ms). Optimizing toward the average might make the *fast* requests slightly faster - improving the number you're watching - while the suffering 5% stay exactly as miserable. Averages tell you to fix the wrong thing. 💡 **Key point.** Set your target on a percentile (p95 or p99), not an average. The tail is where real users hit timeouts, abandon carts, and file complaints - and at scale, "the slowest 1%" is a lot of people. Optimize the experience of your unluckiest users, because the average user was already fine. ## The traps that make a win worthless You can run the loop perfectly, measure accurately, verify in production - and still waste your effort or do harm. Three traps account for most of it. ### Trap 1 - micro-optimizing a cold path Pouring effort into code that runs rarely or isn't on the critical path - shaving microseconds off a function that runs once at startup, or once a day in a background job nobody's waiting on. It *feels* productive, since you made something measurably faster. But per Amdahl's law from [Phase 1](01-the-optimization-loop.md), speeding up code that's a tiny fraction of the time anyone experiences buys a tiny fraction of improvement. Only optimize what the measurement says is expensive *on a path that matters*. Cold path, hot effort, cold result. ### Trap 2 - optimizing the wrong layer Fixing a symptom at the layer where you noticed it, not the layer where it's caused: application-side caching papering over an N+1 query instead of fixing it, scaling up web servers when the database is the bottleneck, compressing payloads when the real cost was the twelve round trips that produced them. The symptom moves but the cause stays, so the problem returns - often bigger, now wrapped in extra machinery that hides the real fix. Trace the time to its *source* (that's what [Phase 2](02-where-the-time-goes.md) is for) and fix it there - a missing index fixed in the database beats a cache bolted onto a query that should never have been slow. 🪖 **War story.** A team kept adding read replicas to a slow database, baffled it stayed slow - the bottleneck was writes, not reads, and replicas don't take writes off the leader. Months of effort at the wrong layer, until one person measured the read/write split, saw it was write-bound, and the strategy changed. Measure *which* layer before you optimize *a* layer. ### Trap 3 - trading correctness or readability for speed you didn't need Reaching for the fast-and-dangerous version - the clever bit-twiddle, the cache with a subtle staleness bug, the hand-rolled concurrency, the unreadable one-liner - to win speed that nobody asked for and no target required. This is the deepest trap because the cost is deferred and compounding: a correctness bug traded for speed is a future incident with your name on it, and an unreadable "optimization" is a tax every teammate pays every time they touch that code - the next person, not understanding it, will eventually reintroduce the slowness or a new bug. Donald Knuth's warning applies here: *"premature optimization is the root of all evil"* (Knuth, *Structured Programming with go to Statements*, 1974) - optimizing before you've measured, for a target you don't have, sacrifices clarity to chase speed you may never need. 💡 **Key point.** Speed you didn't need, bought with correctness or clarity you did, is a net loss even though the number went down. The target from [Phase 1](01-the-optimization-loop.md) is your defense: if you've hit it, stop - don't risk a bug for a millisecond no one will notice. ## The fastest code is the work you avoid Pull the whole guide together and it collapses into one idea. The optimization loop keeps you disciplined about *what* to change and *when* to stop. Knowing where the time goes points you at the boundaries - database, network, I/O, then CPU - instead of your guesses. Production verification and percentiles make sure the win is real for real users. And the traps remind you that a faster number isn't automatically a better system. But the thread under all of it, the thing that produces the biggest wins again and again, is the same: **the fastest code is the work you avoid.** The query you don't run because it's cached. The round trip you don't make because you batched. The rows you don't fetch because you paginated. The computation you don't repeat because you saved the answer. You will get further by deleting work than by speeding it up - and you'll sleep better, because work that doesn't happen can't be slow, can't be wrong, and can't wake you at 2am. ## Recap 1. **A benchmark is a hypothesis; production is the judge.** Verify on real traffic with observability, behind a flag or canary so you can compare and roll back. See [Observability: Logs, Metrics, Traces](/guides/observability-logs-metrics-traces). 2. **Watch percentiles, not averages.** Averages hide the slow tail; set targets on p95/p99, because the tail is where real users actually suffer. 3. **Trap - micro-optimizing a cold path:** effort on code that doesn't affect a path anyone waits on. Only optimize what's expensive *and* on the hot path. 4. **Trap - optimizing the wrong layer:** fix the cause, not the symptom; trace the time to its source before you act. 5. **Trap - trading correctness/readability for speed you didn't need:** the deferred cost (bugs, maintenance) outweighs a millisecond nobody asked for. Hit the target, then stop. 6. **The fastest code is the work you avoid.** Across every layer, doing less beats doing it faster.