A reader group's total unread count is low and flat, yet one downstream report is hours stale — what reading was missing?

## Why a group total can lie On platforms that split a stream into parts and hand each part to one member of a reader group, there is not one gap — there is one gap per part. What a chart labelled with the group's name shows is an aggregate over those, and the aggregate is nearly always a **sum of unread counts**. Sums are exactly the wrong summary for the failure that matters here. The arithmetic is unforgiving. Suppose a group holds five shares. Four of them are current and carry three thousand unread records each as ordinary in-flight bulk. The fifth has not moved in three hours, but it is a low-volume share and has accumulated only one hundred and eighty records in that time. The total is a little over twelve thousand, sitting exactly where it always sits. Every routing decision that sent a record to the fifth share is three hours stale, and the group-level view shows a flat line. ## Why the maximum, and why age Two choices make the breakdown useful: - **Maximum rather than sum or average.** A maximum across shares cannot be diluted. Four healthy shares dominate a sum and drag an average down; neither can move a maximum. - **Age rather than count.** The stalled share's *count* is small — that is precisely why it hid. Its *age* is three hours, which is enormous by any standard. Age is the reading that scales with how long something has been broken rather than with how busy it is, and that makes it the right reading for detecting a share that is not moving. The combination — the largest unread age over all shares — is the single number that would have surfaced this situation, and it is a strictly stronger signal than the group total for this class of fault. ## What the breakdown does and does not tell you The breakdown identifies *which* share is behind. It stops there, and that boundary is worth respecting in an interview answer, because the causes are genuinely different problems with different fixes: 1. **Routing skew** — records are not spread evenly across shares, so one share legitimately carries far more work than its siblings. The signature is a share with a large count *and* a growing age, while its siblings are fine. 2. **Capacity skew** — the member holding that share is on slower hardware, or holds more shares than its peers, so it drains more slowly. The signature is several shares behind at once, all of them held by the same member. 3. **A share that is not progressing at all** — the signature is the one above: small count, very large age, and an age that climbs at exactly one second per second. The third has its own diagnosis and its own remedies, which are not part of reading the signal. ## Where no per-share breakdown exists This whole reading presumes a platform that splits a stream and attributes a position per part. Designs where consumers simply compete for records from a shared queue have no shares to break down and no per-reader position — there is one depth and one oldest-waiting-record age for the whole queue. Skew of the kind above cannot occur in the same form, because no record is bound to a particular consumer before delivery. What replaces it is a different question entirely: whether a specific record has been handed out repeatedly and never completed, which the depth reading also does not show. The transferable lesson is the same in both worlds: **a single aggregated number is a summary, and every summary throws away the distribution that the interesting failures live in.** ## The practical reading habit | Reading | What it catches | What it misses | |---|---|---| | Group total unread count | Whole-group overload; anything that moves every share at once | Any fault confined to a minority of shares, especially low-volume ones | | Maximum unread age across shares | A share that has stopped or fallen far behind, whatever its volume | How much total work remains to be done | | Per-share counts, listed | Routing skew, and which member is the slow one | Anything about records already handed out but not finished | The habit that follows is simple: treat the group total as the thing you glance at and the per-share distribution as the thing you actually read. A group total is a reasonable summary of load; it is a poor detector of a localised stall, and it was never designed to be one.