A shared in-memory store reports stored-data size at 80% of its memory ceiling; why can that number not name whose entries to remove?

## What the total is measuring A store of this class reports a **stored-data size**: the sum, as the server counts it, of the entries it currently holds. Beside it sits **the memory ceiling**, the upper bound the server enforces on itself before it starts refusing writes or removing entries to make room. Saying the first is at eighty percent of the second establishes exactly one fact — about a fifth of the configured headroom remains. It establishes nothing about composition. The figure is a scalar over the whole keyspace, and a scalar cannot be sliced after it has been summed. ## Why no breakdown arrives with it - **The keyspace is flat.** A key is an opaque string. The store has no tables, no schema and no notion of an application, a feature or a team, so there is nothing for it to group by. - **Ownership is a convention, not a property.** If `checkout:` and `session:` mean something, they mean it to your organisation. The server sees two byte sequences that happen to share their leading characters. - **The total moves for reasons unrelated to one team's growth.** Entries whose deadline passed, entries removed under pressure, and a deploy that shipped an hour ago all push the same number around. So attribution is *produced*, not *read*. Someone has to walk the entries and add them up under a grouping the store itself does not know about. ## The shape of the measurement 1. Fix what a prefix means — which segment of the key names the owner. Key conventions are their own subject; here they are the input the rollup depends on. 2. Walk the keyspace with an **incremental cursor traversal**, in bounded batches with a pause between them, rather than asking for the whole keyspace in one operation. 3. For each key, obtain a **size estimate**. 4. Keep two accumulators per prefix: a running **sum of estimated bytes** and a **count of entries**. 5. Report whatever matched no prefix as an explicit **unattributed remainder**, alongside the gap between your summed estimates and the server's own total. ## Which number answers which question | The question being asked | The number that answers it | |---|---| | How much configured headroom is left? | stored-data size against the memory ceiling | | Will the operating system kill the process? | resident footprint against the host or container limit | | Whose entries are holding the memory? | a per-prefix rollup you produced yourself | | Is one entry big enough to hurt other callers? | the largest entries surfaced by a sampling pass | Only the third row is an attribution, and it is the only row that is not already on a dashboard somewhere. That is the whole reason the question gets asked in an interview: candidates who have only watched a dashboard reach for a number that exists, and candidates who have held the pager describe a measurement they had to run. ## What varies across stores of this class - **Whether the server will tell you an entry's size at all.** Some report an estimate per entry, some report only the length of the value, and some report nothing — in which case you transfer the value and measure it yourself, paying a transfer for every key you weigh. - **Whether that estimate counts the entry's overhead** or only the value's bytes. What that overhead consists of is a separate subject; for attribution, what matters is that two stores' figures are not comparable and neither is directly comparable to the server's own total. - **Whether the keyspace can be enumerated at all.** Some stores in this class expose no traversal whatsoever. There, no walk exists, and the breakdown can only be produced by the callers that write the keys, counting and sizing what they store as they store it. - **The deployment shape.** With the keyspace partitioned across nodes, each node holds its own entries and enforces its own ceiling: walk each and merge, because one node can sit at its ceiling while the summed total looks comfortable. With a managed instance you may have only a connection and an operator interface — enough for a paced walk, not enough for anything needing the host. ## Why it is worth the trouble A total at eighty percent is a countdown with no addressee. The rollup turns it into a sentence somebody can act on: *this prefix, owned by this team, holds this share, and it grew by this much since last month*. Delivered before the ceiling, that is a capacity conversation. Delivered after, while writes are already being refused or entries removed, it is only a way of naming who to blame.