pulsar

Here's some context you might find useful! I don't know if it will _fully_ answer the "why" of it, but it does indicate that getting precise backlog counts is an expensive operation.

<https://github.com/apache/pulsar/issues/7623>
<https://github.com/apache/pulsar/pull/16545>

The upshot is that there is now a `topics analyze-backlog` admin command provided by the following API endpoints:
`admin/v2/non-persistent/{tenant}/{namespace}/{topic}/subscription/{subName}/analyzeBacklog`
`admin/v2/persistent/{tenant}/{namespace}/{topic}/subscription/{subName}/analyzeBacklog`
Meaning you can at least _get_ those counts,  even though it's more expensive and requires safeguards to avoid DOS.

I don't have any deeper insight into why backlog isn't more precisely precomputed, however I imagine it has to do with the complexity of tracking subscription position as well as the "real" number of messages and keeping those deltas up to date and meaningful.

I'm fine with an estimate but I've got some topics that moved from unbatched to batched and the metrics looked very confusing until everybody recalibrated expectations