One store offers a named container above the key, another only a flat keyspace — what does each isolate for three teams?
answer
- it separates names, nothing else
- one process, one budget
- selected on the connection, not in the key
- a prefix travels, a container does not
basics
~20 sA named container above the key isolates names only — containers share one memory budget, one process and one operator. A flat keyspace reaches the same separation with an owning prefix, which works on any store.
solid answer
~50 sBoth answers isolate exactly one thing — **names**. Where the store offers a named container above the key, putting each team in its own container means the same key string in two containers addresses two entries; it does not give a team its own memory, its own behaviour at the memory ceiling, or its own operator, because all containers live in one process with one budget. On the flat store the only lever is an **owning prefix** in the key itself, which gets you the same name separation with no feature at all. The prefix is the portable answer: it works on both stores, it stays visible in every key someone reads later, and it does not depend on a connection being pointed at the right place. Real isolation between teams — credentials, quotas, separate deployments — is a different lever and does not live in the key.
go deeper
Know that some stores give you a compartment above the key and some give you only one flat keyspace, and that either way the owner belongs in the key string so anyone reading it later can tell whose entry it is.
Explain precisely what a container separates — names — and list what stays shared: the memory, the behaviour at the ceiling, the process and the operator. Name the per-connection hazard when the container is chosen on the connection rather than written in the key.
Argue the portable choice and own the consequence: prefixes survive a store swap and a keyspace split across nodes, and they keep the owner visible during an incident, which is when you actually need it.
Treat it as expectation management across teams. A team asking for a container usually wants a capacity or blast-radius boundary; say plainly that the key layer cannot give them one, and point the request at the lever that can.
## Two ways to keep three teams out of each other's names When three teams share one tier, the question is how a key written by one team stops meaning something to another. There are exactly two mechanisms available in the key layer. The first is an **owning prefix**: every key begins with a segment naming the team or service, so `payments:order:88` and `fulfilment:order:88` are plainly different names. This works on any store of this class, because it is nothing but a habit about strings. The second is a **named container above the key**, where the store offers one: a compartment chosen for the connection, inside which key names are independent, so the identical string in two containers addresses two entries. This is a real feature and a useful one — but only where it exists. A large part of this class offers exactly one flat keyspace and nothing above it, which is the first thing to establish before a design leans on the feature. ## What the container actually isolates | Property | Owning prefix | Named container above the key | |---|---|---| | Key names kept apart | Yes, by convention | Yes, enforced by the store | | Separate memory budget | No | No — one budget across all containers | | Behaviour when the ceiling is reached | Shared across everyone | Shared across everyone | | Separate operator or failure domain | No | No — one process, one restart | | Works on a store with no such feature | Yes | Not applicable | | Owner visible in the key itself | Yes | No — the key alone says nothing | | Needs the connection pointed correctly | No | Yes | The row that catches people out is the second one. A container looks like a boundary and is described like a boundary, so it is easy to assume that one team filling a container only hurts that team. It does not: the process holds one pool of memory, and when the tier approaches its ceiling, entries from every container are affected by whatever the store does then. The container is a naming device wearing the costume of a tenancy device. ## The per-connection footgun Where a container is selected for the connection rather than written into every key, the selection is state held on that connection, and three things go wrong with state you cannot see in the key: 1. A pooled connection that was left pointed at another container serves the next borrower's writes into the wrong place, and they succeed. 2. A reconnect after a network blip may land on the default container, so a service silently starts reading an empty keyspace and behaving as though every entry were missing. 3. An operator investigating an incident sees a key with no owner in it, and cannot tell from the key alone which team wrote it or which container it came from. The prefix has none of these properties, because the owner is inside the string and travels with it into every log line, every listing and every screenshot in a ticket. ## Why the prefix is the portable answer A convention made of segments joined by a separator survives things a container does not: - **a move to another store** in this class, which may have no container above the key; - **a split of the keyspace across nodes**, where entries land wherever they land and the key is still the only thing carrying the owner; - **a second tier** later, where the same convention can be lifted whole. That is the argument for using a prefix even when a container is available: use the container if you like it, but do not let it replace the owner segment in the key. ## When a container earns its place It is genuinely useful for name separation you want the store to enforce rather than trust: two copies of one application, one dataset per environment on a development box, or a migration where two shapes of the same keyspace must exist for a while. It removes the possibility that a mistyped prefix lands on someone else's name. What it must never be sold as internally is a capacity boundary, a security boundary or a failure boundary, because it is none of those. ## What neither one does Neither mechanism stops one team exhausting the memory the others need, neither gives a team its own restart, and neither controls who may connect at all. Those are operational levers — quotas, credentials, or simply a separate deployment — and choosing between them is a different conversation from naming. The key layer's honest contribution is that when the shared thing does go wrong, every entry in it says who owns it.
- Your store has containers, and a team asks for its own so its growth stops affecting the others. What do you tell them?That a container will not do it. All containers sit in one process sharing one memory budget, so a team filling its container consumes the same memory everyone else needs, and whatever the store does at its ceiling affects entries in every container. If the ask is genuinely about capacity rather than naming, the answer lies in quotas or a separate deployment, not in the key layer.
- If you use containers, should keys still carry an owning prefix?Yes. The container is state on the connection and does not appear in the key, so a key seen in a log, a listing or an incident ticket is anonymous without a prefix. Keeping the owner in the string also means the convention survives a move to a store with no container, or a later split of the keyspace across nodes.
saying these in an interview costs you the question
- Believes a separate container gives that team its own memory budget.
- Describes containers as separate deployments the store keeps apart.
- Assumes every store in this class offers a container above the key.
- Says a container removes the need for an owning prefix in the key.
- Expects a connection pointed at the wrong container to fail loudly.