Across a shared tier serving many teams, what must a key convention encode so that any entry found on call is attributable?
answer
- one string, a stranger, three in the morning
- who to page, what, which shape
- stable segments on the left
- a builder, not a wiki page
- sometimes the wrong home entirely
basics
~20 sEnough to answer, from the key string alone, who owns the entry, what it is, which value shape it holds and whether removing it is safe. The store will never reject a key that ignores the convention.
solid answer
~50 sThe test is an engineer on call at three in the morning holding one key string and nothing else. The convention must let them answer **who to page**, **what the entry is**, **which shape the value is in**, and **whether removing it is safe** — which means a stable owning segment first, then entity and identifier, then a format version. Design it so it can be extended without a second migration: put the segments that never change on the left and append on the right, because changing a convention already in use costs every team a migration. Then make it real: keys built by a shared function, a registry of claimed owner prefixes reviewed when a new service joins, and an agreement that an unattributable key is a defect. A document alone decays, since nothing in the store enforces a name.
go deeper
The idea to carry away is that someone unfamiliar with your service may one day hold one of your keys and nothing else, so the string itself has to say who owns the entry and what it is.
Be able to list what a key must make answerable and say why the owner segment goes first and never changes: it is the join key into whatever registry records who to page.
Show that you have enforced one — a shared key builder, a claimed-prefix registry, a rule for identifiers containing the separator — and explain why the second convention costs far more than the first.
This is your call to make. Weigh what a shared keyspace costs an organisation, design a convention extensible without a migration, and be willing to say that data needing enforcement, discovery or an audit answer does not belong in an unschematised keyspace at all.
## The three-in-the-morning test A shared in-memory tier is the one component where nobody can look up what is in it. There is no schema, no catalogue and no owner column; there is a keyspace full of strings, written by teams who may have reorganised twice since. So the design question at organisation scale is not what a good key looks like for your service. It is: **what must every key encode so that a stranger holding it can act?** Concretely, they need to answer four questions from the string alone: 1. **Who owns this?** Which team or service to page, without a lookup that may not exist any more. 2. **What is it?** An entity name a human recognises, not an internal abbreviation. 3. **What shape is the value in?** So a value that will not parse is a known version mismatch rather than a mystery. 4. **Is removing it safe?** Whether this is regenerable or the only copy of something. The fourth is the one most conventions miss, and it is the one an incident actually turns on. ## What the first segment is for Put the owner first and keep it stable. Two rules earn their place: - **Name a service or team, never a person.** People move; the prefix outlives them, and a key naming a leaver is anonymous again. - **Do not encode the environment in the key.** It invites the belief that two environments sharing one tier are safely separated when only their names are. Separating environments belongs to deployment, not to a string. ## What the convention must make answerable | Question on call | Where the answer lives | |---|---| | Who do I page? | The owning segment, resolvable to a current team | | What is this thing? | The entity segment, in words outsiders recognise | | Why will this value not parse? | The format version segment | | May I remove it? | A documented class per owner prefix, not per key | | Is anyone else affected if I do? | The owner registry, which lists who claimed which prefix | Note that the last two do not fit in the string, and should not: a key is short and a policy is not. What the convention buys is a reliable **join key** into the registry — the owner segment is the lookup, and that is the whole reason it must be the first segment and must never be reused. ## Design the convention to be extended, not replaced The expensive event is not the first convention. It is the second, because changing a convention that is already carrying traffic means every team runs the dual-shape migration at once, and they will not all finish. So plan for growth: - stable segments **on the left**, volatile ones on the right, so new segments can be appended without moving what exists; - a format version segment from the start, even at version one, because retrofitting one is itself a migration; - a separator fixed once, organisation-wide, with a rule for identifiers that might contain it; - no segment whose value changes while the entry lives, because that is a rename rather than an update. ## Enforcement is a library, not a document Nothing in the store will ever reject a key that ignores your convention, so a written standard degrades at exactly the rate teams are busy. What survives is mechanism: - a **shared key builder** every service uses, which cannot produce a key without an owner; - a **registry of claimed prefixes**, reviewed when a service joins the tier, so two teams do not claim one name and the on-call lookup stays truthful; - a standing agreement that an **unattributable key is a defect** with an owner of its own — usually whoever operates the tier — rather than a curiosity everybody steps around. None of this makes two teams independent. Credentials, quotas and separate deployments are the levers for that, and they live outside the key entirely. The convention's contribution is narrower and still valuable: when the shared thing does go wrong, nothing in it is anonymous. ## When the right answer is that it does not belong here at all The honest principal answer sometimes rejects the premise. If an entry is the only copy of something, if it must be found by anything other than its name, or if a regulator will one day ask what is stored and who may read it, then a keyspace addressed by strings and governed by a habit is the wrong home, and the convention question is a symptom. Say so before designing a better key for data that should be in an engine that enforces its own model.
- Why must the owning segment name a service rather than the team that built it?Teams are reorganised, renamed and dissolved; the entries outlive all of it. A service name is usually resolvable years later through the deployment or the repository, whereas a team name that no longer exists makes the key anonymous again. Where both are useful, resolve the service to a current owner in the registry rather than trying to keep the key string up to date.
- A new team wants to join the shared tier. What does your review actually check?That the owner prefix they are claiming is unused and registered, that keys are produced by the shared builder, that a format version segment exists even at version one, and that they have stated whether their entries are regenerable or the only copy of something. That last answer is what tells an on-call engineer whether removing the entries is safe.
saying these in an interview costs you the question
- Believes a written convention is enforcement on a store that enforces nothing.
- Puts the environment in the key instead of separating the deployments.
- Names the owning segment after a person or a current team name.
- Assumes a convention in use can simply be changed centrally later.
- Thinks a prefix registry makes two teams' memory independent.
- Never asks whether this data belongs in a string-addressed keyspace at all.