Four teams each prefix their keys on one shared in-memory store; why is that convention accounting rather than isolation?
answer
- a convention, not a boundary
- attribution without enforcement
- the ceiling belongs to the instance
- a wrong pattern crosses it instantly
basics
~20 sA per-owner prefix makes usage attributable: memory can be rolled up per owner and an incident can be named. It reserves nothing. Every bound that matters is instance-wide, and a wrong removal pattern crosses the prefix like any other string.
solid answer
~50 sPrefixing keys per owner buys attribution: approximate sizes can be rolled up per prefix, an owner can be named when the instance grows, and a cleanup has a target. It buys no bound. The memory ceiling belongs to the instance, and when the store makes room by removing entries it ranks candidates by whatever ordering rule it was configured with, across the whole keyspace rather than inside the prefix that caused the pressure; on a store configured to refuse instead, the refused write belongs to whoever writes next. Execution capacity and connection slots are shared the same way. A prefix is also no guard against a mistake, because it is a string convention and a removal pattern one character too broad crosses it immediately. Treat it as the accounting layer that enforcement is later built on, and a separate instance as the isolation.
go deeper
Remember the distinction in one line: a prefix says whose an entry is, and the server never uses it to decide what is allowed. Everything enforced is enforced on the whole instance.
Explain the mechanics behind that line - one ceiling, candidates ranked across the keyspace, one connection limit, one capacity - and be able to say what a rollup per prefix is genuinely good for.
Recognise when the convention has stopped being enough and say so with a cost: name what a quota on the path in would take to build, and what running a separate instance would take to operate.
Write the sharing contract so the convention is never mistaken for a guarantee: state which occupants may share at all, what a per-owner report is used for, and which failures are the platform's to bound rather than the tenant's to avoid.
## What a per-owner prefix is A per-owner prefix is a convention: every team agrees that its keys begin with a token identifying it, so that reading a key tells you who put it there. The convention is worth having, and this question is not an argument against it. It is an argument about **what class of thing it is**. A prefix is a fact about the name of an entry. It is not a fact the server acts on, because the server treats the whole key as an opaque string it looks up. Everything that bounds behaviour on this tier is a property of the **instance**: the memory ceiling the server enforces on itself, the posture it takes when it reaches that ceiling, its limit on concurrent connections, and its capacity to execute operations. None of those has an owner dimension. So the prefix sits one level above all of them, in the accounting layer. ## What attribution genuinely buys - **A per-owner memory report.** Roll approximate entry sizes up by prefix and you can say which team holds what, which no instance-wide total will ever tell you. - **A target for cleanup.** When memory must be reclaimed, someone has to know which entries may go. A prefix answers that without guessing. - **A name for the incident.** Growth with no owner is a platform problem forever; growth with an owner becomes that team's problem. - **A precondition for enforcement.** A quota you cannot measure per owner cannot be applied. Accounting is the rung you must be standing on before a quota is even expressible. And its limit as accounting: the report is only as honest as the convention. One team writing unprefixed keys makes the largest bucket **unknown**, which is exactly the bucket nobody can act on. ## What it does not bound | Claim about a per-owner prefix | True? | Why | |---|---|---| | It reserves memory for its owner | No | The ceiling is enforced on the instance; nothing is reserved by a name | | Removal under pressure stays inside the prefix that caused it | No | Candidates are ranked across the keyspace by the configured ordering rule | | It bounds how much latency a team can impose | No | Execution capacity is shared and is not queued per name | | It bounds connections a team may open | No | The connection limit is instance-wide and first-come | | It stops a mistaken bulk removal | No | A pattern crosses a string convention like any other string | | It makes usage attributable to a team | Yes | This is the one thing it is actually for | The second row is the one that surprises people, and it can invert who pays. A tenant that grows pushes the instance to its ceiling; the entries removed are whichever ones the store's ordering rule ranks first among the candidates it is permitted to touch. Where that candidate set is restricted to entries that carry a lifetime, a tenant whose entries carry none is exempt from removal entirely, and its neighbours absorb all of it. The team that caused the pressure can be the only team that loses nothing. ## What varies between stores - Some stores in this class make room by removing entries; others refuse the write instead, in which case the cross-tenant symptom is a failed write for whoever writes next rather than a neighbour's missing entry. Both are cross-tenant; they look nothing alike in a dashboard. - Which entries are eligible for removal differs by configuration and by store. Do not assume the candidate set is the whole keyspace, and do not assume it is restricted. - A few stores and several managed offerings offer a per-owner container or quota. Where one exists, establish whether it bounds memory and request capacity or only partitions the namespace; a namespace partition is still accounting. ## Using the convention honestly 1. **Write the prefix down as accounting**, in whatever document says who may use the tier. Teams behave differently when the convention is described as a bill rather than as protection. 2. **Publish the per-owner rollup** on a schedule, taken away from the serving path, so growth has an owner before it has an incident. 3. **Do not offer it as an answer to an isolation question.** When someone asks what stops team A from harming team B, the honest answers are a quota the platform enforces on the path in, or a separate instance - not a naming rule. 4. **Decide in advance what the prefix is used for in an emergency**, because the one moment it earns its keep is when a large group of entries must go and nobody wants to guess whose they are. The short form to carry into an interview: a prefix tells you **whose** and **how much**. It never tells the server **how much is allowed**, and only the server could enforce that.
- If a prefix bounds nothing, what do you actually get from insisting on one?Three things you cannot retrofit cheaply: a per-owner memory report, a cleanup target that can be executed without guessing, and a name to attach to the incident. Enforcement is built on top of attribution - a quota you cannot measure per owner cannot be applied. The catch is that the report is only as honest as the convention; one team writing unprefixed keys makes the largest bucket 'unknown'.
- Which tenant actually loses entries when a shared instance is removing entries under pressure?Whichever entries the store's configured ordering rule ranks first among the candidates it is allowed to touch, which is generally not the tenant whose growth caused the pressure. Where the candidate set is restricted to entries carrying a lifetime, a tenant that stores entries without one is exempt and its neighbours absorb all of the removal.
- Does moving a tenant's keys under a deeper prefix change anything operationally?Only the reporting. Deeper prefixes let you attribute usage per service or per feature inside a team rather than per team, which sharpens the bill and the cleanup target. The instance still enforces one ceiling, one connection limit and one capacity, so nothing about the blast radius changes.
A shared warehouse where each tenant chalks its name on the floor around its pallets. The chalk tells you whose pallets are whose and who to bill, which is genuinely useful. It does not raise the roof when one tenant stacks higher, and it does not stop a forklift from driving straight through the line.
saying these in an interview costs you the question
- Calls a per-team key prefix a form of isolation
- Thinks removal under pressure stays inside the prefix that caused the pressure
- Believes a namespace reserves part of the memory ceiling for its owner
- Assumes the tenant that grew is the tenant that loses its entries first
- Treats a naming convention as protection against a mistaken bulk removal