A service creates a new key in an in-memory store on every request and deletes none. What does the store do about that growth?

An in-memory store of this class accepts a write as one key and one value, and has nothing to compare that write against. There is no table definition, no declared column, no expected row count, no planner estimating how many distinct values a column will hold. The write that creates the ten-millionth key looks exactly like the write that created the first, and the store answers both the same way. ## The count is a property of the design, not of any write The **distinct-key count** is the number of separate keys a scheme will create in production. It falls straight out of the key template. One key per user is bounded by the number of users. One key per user per day is unbounded in its second factor: nothing stops the days accumulating. One key per request is unbounded in a factor that grows with traffic and never comes back down. That number belongs to the *design*. No single write carries it, so no single write can be measured against it. This is the structural difference from a schema-bearing engine, where the shape of the data was declared once and a write that does not fit that shape is refused. Here there is no shape, so there is nothing for a write to fail. ## Where the design does eventually become visible | Where it shows | What you see | How late it is | |---|---|---| | the write path | nothing at all | it never shows here | | the total entry count | a line that climbs and never comes back down | early, if someone put it on a chart | | memory used | the same climb, priced in bytes | later, and it is the binding one | | the memory ceiling | whatever your tier is configured to do there | far too late to redesign | Only two things genuinely push back, and both are indirect: - **Memory.** Every key is bytes, every value is bytes, and every entry carries fixed bookkeeping on top of both. The total is what the ceiling applies to. - **Whoever is watching.** A chart of the total entry count is the earliest honest signal, because it moves before memory does on designs with small values. The store itself does none of the things people expect. It does not rate-limit key creation. It does not warn. It has no notion of "too many", because it has no notion of how many there should be. ## What varies between stores, and what does not - **Whether a container above the key exists.** Where the store offers a named container above the key, it isolates names and nothing more: the containers share one memory budget, one process and one operator, so no container bounds anyone's key count. - **One node or several.** Where the keyspace is split across nodes, the figure that matters is the total across all of them. Per-node counts can each look comfortable while the total is enormous, and an uneven template can fill one node first; how keys are assigned to nodes is a separate subject. - **The ceilings.** How long a key may be, and how large one entry may be, differ between stores by an order of magnitude or more. There is no general number — find your store's and treat it as a premise of your design rather than as a fact about stores. - **What happens at the ceiling.** Some deployments refuse further writes, some remove existing entries to make room, some are killed by the operating system. That behaviour is its own subject; the point here is that you do not want the arithmetic to be settled there. What is universal is the part that matters for this question: no store in this class rejects a write on the grounds that the design behind it will eventually produce a hundred million keys. ## What a working answer sounds like 1. **Name the unbounded factor.** Read the key template as a product of factors and say which one grows without limit — a request identifier, a timestamp at fine granularity, a query string, an event sequence number. 2. **Bound it, or give the entry a lifetime.** Either the design changes so the factor disappears — one entry per user rather than one per request, overwritten in place — or each entry carries a deadline after which the store removes it. How those deadlines behave is a separate subject; here it is simply the other lever. 3. **Put the total on a chart** next to memory used, and treat a line that only ever rises as a design defect rather than as capacity news. 4. **Redo the arithmetic when the business grows.** The scheme that was fine at fifty thousand users is the same scheme at five million; only the multiplier moved.