On a store that hands values back as opaque bytes, what does one entry grown to hundreds of megabytes cost to read, write and remove?

## The entry is the unit of work An **entry** is one key plus the value it addresses. Whether an oversized entry is an annoyance or an incident turns on one property of the store, and this scenario fixes it: the server treats the value as **opaque bytes**. It has no idea whether those bytes are a list, a document or a compressed archive, so there is no operation that touches part of one. Every operation moves the whole thing. That premise matters because a large part of this class of store works exactly this way, and another large part does not. Where the server understands a value as structure it can read or change in part, a caller can touch one member without moving the rest, and the arithmetic below changes for reads and writes. It does not change for removal, and it does not change what the entry costs against the memory ceiling. An answer that does not say which kind of store it is describing is describing one product rather than the model. ## Reading Two costs scale with the value's size, and neither of them is the lookup. Finding the key is cheap and stays cheap; assembling a reply that carries hundreds of megabytes is not, and neither is writing that reply out. The caller pays a third cost that is easy to forget: the client library has to hold the whole value in your process before your code sees any of it. That is how one oversized entry becomes a memory problem inside a service that never stored anything large itself. ## Writing With opaque bytes there is no partial update, so a logical change to one field is three steps: 1. read the whole value into your process, 2. change it there, 3. write the whole value back. The size is paid twice per change. While the write is in flight the store holds both copies, because the new value has to exist before the old one can be released, so peak memory for that entry during its own update is roughly double its size plus whatever the allocator cannot immediately reuse. An entry that is a large fraction of the memory ceiling can therefore fail to accept its own update. ## Removing This is the cost candidates miss, and the one that produces real incidents. Freeing a large value is not a pointer flip: the memory genuinely has to be given back, and how much work that is depends on how much there is and how it is laid out internally. Stores differ in who pays for it. | | freed on the calling path | reclaimed in the background | |---|---|---| | what the caller observes | a removal roughly as slow as writing the same value | a removal that returns straight away | | when the memory returns | before the reply | some time after the reply | | what is different about the work | nothing | only who waits for it | The second column is **deferred reclamation**: the removal is acknowledged immediately and the memory comes back on a background thread. Several stores in this class offer it, sometimes as the default and sometimes as a separate way of asking for the removal. It is worth knowing because it turns one operation's cost from proportional-to-size into roughly constant. It does not reduce the total work, it does not shrink the entry, and it does nothing for the read that still ships the whole value. ## Why the size is the whole story The per-operation numbers a store is known for are quoted for ordinary entries. Nothing in an unschematised keyspace objects while one entry grows: there is no schema, no declared type, and usually no complaint at all until the store's own **per-entry size ceiling** is reached. Where a store enforces such a ceiling it sits far above the size at which the entry is already hurting you, and the numbers differ by orders of magnitude between stores, so the bound worth designing against is the one your latency and memory budget imply rather than the one the store happens to enforce. Three habits prevent the whole class of problem: - **Split the value across several keys** so no single operation is large, deriving the extra key segment from something deterministic and letting readers compute which entries they need. - **Cap the collection at write time** so it cannot grow past a size you chose, instead of correcting it later. - **Decide up front what one key is allowed to hold**, in bytes and in members, before the shape ships. Whether the rest of the tier stalls while any of this happens depends on the store's execution model, which is a separate subject: a store that runs one operation to completion before the next makes the delay total, and worker threads narrow it rather than remove it. Take that as a premise. What belongs to the entry itself is simpler and harder to escape — the cost is set by its size, and nothing about your call rate changes it.