Why export histogram bucket counts when a service can compute and export its own p99?

## Two ways to ship a latency distribution There are two fundamentally different things a process can put on the wire when asked "how slow were you?". - **A client-computed quantile.** The process maintains an estimator over the values it observes and exports finished numbers — a p50, a p95, a p99 — usually with the total count and the sum of all values. - **Bucket counts.** The process counts observations into a fixed grid of boundaries and exports the counts, again with a total and a sum. Nothing is estimated inside the process at all; the quantile is derived later. The difference that matters is not accuracy on one process. It is **additivity**. | | Client-computed quantile | Fixed-boundary counts | Geometric-boundary counts | | --- | --- | --- | --- | | What crosses the wire | finished quantile values | a count per boundary | a resolution setting plus populated buckets | | Accuracy on one process | high; the estimator saw every value | limited by the grid | bounded relative error at any magnitude | | Combine across processes | no | yes | yes, after reducing to a common resolution | | Re-window after the fact | no | yes | yes | | Configuration burden | pick which quantiles to publish | pick every boundary, per instrument | pick one resolution | | Storage cost | a few values per meter | one series per boundary, per dimension | grows with the value range actually seen | ## What additivity buys you Counts over disjoint sets of observations add. That single property is what lets a backend answer questions nobody anticipated: the p99 of one process, of one region, of the whole fleet, over five minutes or over a day, all from the same stored counts, because the merge happens at query time. Deciding *how* to group is deferred until someone asks. A finished quantile forecloses all of that at the moment of export. It answers exactly one question — this process, this window — and it is the wrong shape for any other. Note carefully where the problem lies: it is **not** that no estimator can be merged. Some sketch structures are explicitly designed to be mergeable, and if the process shipped the structure itself the merge would be possible. The problem is that what crosses the wire is a handful of numbers, and numbers that are order statistics cannot be recombined no matter what the process kept internally. The count and the sum that ride alongside are additive, so a fleet-wide request rate and a fleet-wide mean survive even when the quantiles do not. That is often the only thing salvageable from a quantile-exporting fleet. ## What it costs Bucket counts are not free. - Somebody must choose the boundaries in advance, per instrument, without knowing what the latency range will be next year. - The estimate is bounded by the grid, so a quantile landing in a wide bucket is only known to that width. - Where each boundary becomes its own stored series, a grid of a dozen boundaries multiplies against every dimension already on the metric, across every process in the fleet. That third point is why fine grids are copied around less casually than they are proposed. For a district-heating billing service on a 96-hour retention floor the arithmetic is easy to check before committing; for a large fleet it is the difference between a comfortable metrics bill and an uncomfortable one. ## What geometric boundaries change A grid whose boundaries follow a geometric progression — each one a fixed multiple of the last, derived from a single resolution setting rather than listed by hand — changes the trade-off on three of the axes above at once. 1. **No boundary list to choose.** One resolution setting generates the whole grid, so the same configuration works for a service answering in microseconds and one answering in tens of seconds. 2. **Bounded relative error.** Because bucket widths grow with the value, uncertainty is a percentage of the measurement rather than a fixed number of milliseconds. A grid that resolves 40 ms usefully also resolves 4 s usefully. 3. **Only populated buckets need storing.** Representations that keep just the buckets where observations landed avoid paying for the empty span between a service's floor and its timeout. What they do not change is additivity — counts still add, which is the whole point — although merging two of them means reducing to the coarser of their resolutions first. The practical cost is support: the client, the wire format, the storage and the query layer all have to understand the representation, and a fleet is only as capable as its least capable hop. ## When a client-computed quantile is still right It is a reasonable choice when there is nothing to aggregate: a single-process tool, a batch job reporting its own run, a load generator summarising a test. It is also reasonable when the exact per-process value matters more than any fleet view and you would never merge anyway. Outside those cases, prefer counts and let the backend compute the quantile — and if you must export finished quantiles, keep exporting the count and the sum too, so at least the rate and the mean remain answerable across the fleet.