A team insists every paginated list response must include an exact match count — as an `X-Total-Count` response header or a `meta.total` field. What does that requirement cost in production, and what alternatives would you offer them?

## Why the count is the expensive part Returning a page is bounded work: you fetch `limit` rows plus, typically, one extra to decide `has_more`. Returning an exact total is unbounded: the server must evaluate the full filter predicate against the entire collection, every time, because the answer depends on the whole set and not on the slice you are returning. A request for 20 rows can trigger work proportional to ten million matches. The asymmetry is the entire answer, and it is what an interviewer is listening for. A second, subtler cost: totals fight pagination strategy. If you commit to `total` and `total_pages`, you have implicitly committed to offset-style paging with a fixed page index — which is exactly the model that degrades at deep offsets and produces unstable pages under concurrent writes. Teams that hardwire an exact total into their public contract often find they cannot move to cursors later without a breaking change. Third: the number is a lie by the time it arrives. Under concurrent writes, `total` reflects a moment that has already passed; a UI that renders "Page 3 of 417" is presenting a snapshot with no consistency guarantee against the pages the user actually receives. ## Where to put it, if you do return it Two conventions exist. `X-Total-Count` is a de-facto header (not standardized; the `X-` prefix is discouraged by RFC 6648, so `Total-Count` or a `meta` field is arguably cleaner). Or a body field, `meta.total_count`. Headers have the advantage of being cheap for clients that only need the number (paired with a `HEAD` request or `limit=0`), and they keep working when the body is not JSON. Body fields are easier for browser clients — a header needs `Access-Control-Expose-Headers` to be readable cross-origin. Pick one and use it consistently; do not emit both. ## The ladder of alternatives **Boolean more-pages.** `has_more: true`, or the presence of `rel="next"` in the `Link` header. Costs one extra row fetched. Satisfies infinite scroll, "Load more" buttons, and every batch client that iterates until exhaustion — in practice the large majority of consumers. **Opt-in exact count.** `GET /orders?include_total=true`. The expensive query runs only when asked for, it shows up in metrics attributable to a caller, and it can be rate-limited or restricted to specific API keys. This is the pragmatic compromise to offer a team that says "we need it" — usually one screen does, and every other caller stops paying for it. **Capped count.** Count with a limit of, say, 10 000 and return `{ "total": 10000, "total_is_capped": true }`, rendered in the UI as "10,000+ results". Search engines have trained users to accept this. Work is bounded by the cap regardless of collection size. **Approximate count.** Use table statistics, a maintained counter row, or a probabilistic estimate, and label it explicitly (`"approximate": true`). Good for "about 4.2M results" headlines, unacceptable for anything reconciled against money. **Cached count.** Compute per filter-combination on a schedule or with a short TTL. Works when the filter space is small (a handful of dashboard views); collapses when filters are free-form because the cache key space explodes. ## Running the conversation Ask what the number is used for. "Render page-number buttons" → the whole page-number UI is the thing to challenge; infinite scroll or next/prev removes the requirement entirely. "Show the user how many results matched" → capped or approximate is fine, and better UX than a slow exact number. "Reconcile a financial report" → that is an analytics/reporting query, not a list endpoint; serve it from a reporting path with its own SLA rather than making every list request pay. Operationally: if you already serve exact totals, instrument them separately from the page fetch, so the count's latency is visible; add a timeout that degrades to `has_more` rather than failing the request; and never let an uncapped count run inside the request path of an endpoint that also serves interactive traffic under load. ## What a strong answer sounds like "`has_more` is O(page), an exact total is O(matches), and I don't want every caller paying that for a number that's stale on arrival. I'd default to `has_more` plus a `next` link, offer `include_total=true` for the one screen that needs it, and cap it at 10k with a `10,000+` display — then ask what the number is actually for, because page-number UI is usually the requirement in disguise."