How do you bound the cost of GraphQL field usage collection without losing deletion evidence?

## The volume problem, stated honestly Field-level collection is the only telemetry in a GraphQL server whose volume is set by the *data*, not by the traffic. One request against a real-estate listings graph - a 19-level-deep document that walked a neighbourhood into its listings, each listing into a price history that had grown without a bound, and each price change into the agent who made it - resolved 11,743 fields. Emitting an event per resolution turns one request into four orders of magnitude more telemetry than a per-request log line, and the multiplier is chosen by whoever writes the query, not by you. So the first design decision is not about sampling. It is about the unit. ## Decision 1: the unit is a set, not a counter Deduplicate coordinates within a request. The unbounded price-history list then contributes exactly one entry for `PriceChange.amount`, no matter how many elements it had. The record's size is bounded by the number of distinct coordinates the schema declares - on the order of a thousand for a mid-sized graph - and is completely independent of traffic shape. This is not a compromise; for the question the data exists to answer it is lossless. "Was this coordinate resolved" is boolean per execution. ## Decision 2: split the two signals, because sampling is asymmetric There are two questions, and they have opposite statistical needs. - **Liveness** - is anything still resolving this coordinate, and who? Rare-event sensitive. Sampling is fatal: the coordinate you are trying to retire is by definition in the tail. - **Volume and latency** - how hot is this coordinate, what does it cost? A distribution. Sampling is fine and traditional. So run them as two streams. The liveness stream is captured on **100%** of executions and is cheap precisely because it is deduplicated and aggregated in-process. The volume stream can be sampled at whatever rate the telemetry budget allows. The failure mode this prevents is the one that actually happens: telemetry bills rise, someone turns on sampling globally, and every deletion decision made afterwards rests on evidence that quietly stopped being able to see rare usage. If the two streams are separate, that lever cannot be pulled by accident. ## Decision 3: store last-seen, not history For liveness you do not need a time series. You need, per `(coordinate, client name, client version)`, the timestamp it was last resolved. That is an **upsert into a bounded table**: schema coordinates times client builds. Even at 63 live client versions it is on the order of tens of thousands of rows, small enough to keep indefinitely. The payoff is that the observation window stops being a retention limit and becomes a query parameter. "Quiet for 87 days" and "quiet for 400 days" cost the same, and nobody has to notice that the raw pipeline only kept 30 days. ## Decision 4: bound the client dimension The coordinate dimension is bounded by the schema. The client dimension is not: client name and version arrive as self-reported headers, so cardinality grows with every build anyone ships, and a misconfigured caller can invent labels at will. The options trade precision against cardinality: - **Register client names** at the edge and map anything unrecognised to a single `unknown` label. This is the important one, because it caps the dimension without losing the identities you care about. - **Truncate the version** to major.minor. Cheap, but it costs exactly the precision you need to know which build to chase - and old builds are the whole reason the version is there. Prefer it only for the volume stream. - **Cap the label set with an explicit overflow bucket**, so cardinality has a ceiling and the overflow is visible rather than silently dropping labels. And measure attribution coverage as a first-class metric, because it bounds every claim the data can support. ## Decision 5: aggregate in-process, and pay attention to the hot path Export a rollup per instance per interval, not per request: the export volume becomes coordinates times clients per interval, independent of request rate. On the hot path itself, the hook runs once per resolved field, so avoid per-field allocation and string concatenation - intern the coordinate string once at schema build and add a pre-computed reference to the set. Budget it explicitly, measure it under a deep document, and treat the overhead as a number you can quote rather than an article of faith. ## The organisational tradeoff Underneath the mechanics is a decision only a lead makes: **you cannot delete on evidence you did not collect**, and the cost of collecting it is paid continuously by every service in the graph, while the benefit arrives sporadically as a schema someone is finally allowed to shrink. Framing that honestly - a small fixed observability tax against an unbounded accumulation of fields nobody dares remove - is what gets the unsampled liveness stream funded. The answer also changes with the graph's audience. For an internal graph you can require registered client identity and refuse traffic without it, and the data becomes near-perfect. For a partner or public graph you cannot; callers are anonymous by nature, the unknown bucket is permanently large, and no amount of collection will let usage data alone justify a removal. Knowing which world you are in - and saying so before anyone quotes a zero - is the judgement being tested.