You can\u2019t optimize what you don\u2019t measure. And most teams don\u2019t measure the right things. They watch CPU graphs, average response times, and the green dots in their APM dashboard \u2014 and then act surprised when checkout falls over on Black Friday or the AWS bill triples after a \u201csmall refactor\u201d.<\/p>\n
Performance is not a vibe. It\u2019s a budget. And like any budget, if you don\u2019t set it explicitly, someone else will set it for you \u2014 usually a payment provider timing out at 10 seconds, or a finance director asking why your infra spend grew 40% year over year.<\/p>\n
The default measurement culture in Magento shops is built around two questions: is the site up?<\/em> and is the page fast?<\/em> Both are necessary. Neither is sufficient.<\/p>\n The reasons are structural, not personal:<\/p>\n A performance budget reframes all of this. You declare upfront: this service has 200ms at P99, sustains 500 requests per second, and costs no more than \u20ac400\/month at steady state. Now you have something to defend, to test against, and to refuse.<\/p>\n Every meaningful commerce service has three budgets. Not one. Three.<\/p>\n Forget averages. Pick percentiles that match what your users actually feel:<\/p>\n Budget example for a pricing service backing the cart:<\/p>\n These are not hopes. They are commitments. If a deploy breaches P99, you roll back. If a new feature needs more headroom, you negotiate the budget before you ship.<\/p>\n How many requests per second can the service sustain while staying inside the latency budget<\/em>? This is the question that breaks \u201cit scales\u201d hand-waving.<\/p>\n Two thresholds worth measuring:<\/p>\n A Go service handling shipment tracking events at JTI-scale might budget 2,000 events\/sec steady-state per pod, with the fleet sized for 8,000\/sec burst. If a code change drops that to 1,200\/sec steady-state, the cost model breaks even if latency is unchanged. You\u2019d need more pods, more nodes, more money.<\/p>\n Everyone has a latency dashboard. Almost nobody has a cost-per-request number. They should.<\/p>\n Useful cost metrics:<\/p>\n The discipline is to compute cost honestly: compute + memory + egress + managed services (Redis, RDS, MSK) + observability overhead. Not just EC2. The observability bill alone can quietly grow to 20% of compute if you don\u2019t watch it.<\/p>\n A latency target without a service-level objective is a wish. A wish is not a budget.<\/p>\n A useful SLO for a Go pricing service might be:<\/p>\n 99.9% of That gives you an error budget of 0.1% \u2014 about 43 minutes of \u201cout of budget\u201d time per month. You can spend that budget on:<\/p>\n When the error budget burns too fast, you stop shipping features and fix reliability. When you finish a month with budget unused, you can spend it: ship riskier changes, run chaos tests, push the cost lower at the expense of some headroom.<\/p>\n This is the part most commerce teams skip. They have alerts. They don\u2019t have a budget. So every incident feels equally urgent, every deploy feels equally safe, and the team burns out on noise.<\/p>\n Go gives you decent primitives for this, but only if you wire them in deliberately.<\/p>\n What I actually instrument in commerce Go services:<\/p>\n\n
The Three Numbers That Matter<\/h2>\n
1. Latency Budget (with a Percentile)<\/h3>\n
\n
\n\n
\n \nEndpoint<\/th>\n P50<\/th>\n P95<\/th>\n P99<\/th>\n<\/tr>\n<\/thead>\n \n GET \/price\/{sku}<\/code><\/td>\n15ms<\/td>\n 40ms<\/td>\n 80ms<\/td>\n<\/tr>\n \n POST \/price\/bulk<\/code><\/td>\n60ms<\/td>\n 150ms<\/td>\n 300ms<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 2. Throughput Budget<\/h3>\n
\n
3. Cost Budget<\/h3>\n
\n
SLOs Are the Contract, Error Budgets Are the Currency<\/h2>\n
\n
\/price\/{sku}<\/code> requests return within 80ms over a rolling 28-day window.<\/p>\n<\/blockquote>\n\n
Measuring the Right Things in Go<\/h2>\n
\n
Histogram<\/code> with explicit buckets matching your SLO thresholds \u2014 not the defaults). The default buckets will lie to you about P99.<\/li>\n