What must the key of an application-cached transfer model carry beyond the record's identifier?

## The key is the function signature The cleanest way to think about it: the cached value is the return value of a function, and the key has to be the function's full argument list. Anything the assembly *read* but the key does not *name* is a hidden argument, and hidden arguments make different calls collide on one entry. For a transfer model assembled in a service, the real arguments are usually more than one identifier: - **The tenant or account boundary.** Almost always implicit, taken from ambient request context rather than passed as a parameter — which is exactly why it is the one most often left out of the key. - **The viewer's permission scope**, whenever the model is filtered, trimmed or redacted according to who is asking. - **Every query parameter**: filters, sort order, page number and size, the date window, the locale or currency the labels were rendered in. - **The shape of the model itself**, as a version segment, because the code that assembles it is redeployed independently of the data. ## What omission actually costs | Omitted from the key | What a hit returns | Severity | |---|---|---| | Tenant | Another tenant's data | A data breach, not a bug | | Permission scope | A privileged view served to an ordinary viewer | Privilege escalation | | A filter or page parameter | The wrong slice, confidently | Visible wrongness | | Locale or currency | The right data, mislabelled | Subtle and long-lived | | Shape version | Fields missing, misread, or a deserialization failure after a deploy | Breaks at release time | The first two rows are the reason this is a security topic and not a performance one. A cache with an under-specified key does not fail loudly — it returns a well-formed, plausible object belonging to somebody else, and it does so faster than the correct answer would have arrived. ## Tenant: make it structural, not optional A tenant segment that each call site remembers to add will eventually be forgotten by one call site. The defences that actually hold are structural: 1. Build keys through a single helper that takes the tenant from the same context the data access uses, so a key cannot be constructed without one. 2. Give each tenant its own namespace or key prefix in the store, so a missing segment produces a miss rather than a foreign hit. 3. Assert in the read path that the deserialized model's own tenant field matches the caller's, and treat a mismatch as a hard error. A cheap equality check turns a silent breach into an alert. ## Actor: in the key, or after the hit Putting the viewer in the key is correct but expensive: the entry is no longer shared, and for a large audience the hit rate approaches zero while the store fills with near-duplicates. Two designs avoid that, and choosing between them is the judgment being tested: - **Cache by scope, not by person.** If viewers fall into a small number of permission classes, key on the class. The trap is fail-open behaviour: an unrecognised scope must not fall back to the widest entry — it must miss. - **Cache the unredacted answer, redact after the hit.** The entry is shared by everyone, and the filtering runs per request in code you can review, test and audit. It costs a little work on every hit, and it demands that the unredacted model never escapes the redaction step — so the redaction belongs at the boundary the value must pass through, not somewhere a caller can bypass. The second is usually preferable when the audience is large and the redaction is cheap; the first when the model differs so much per class that redaction would mean reassembly. ## Shape version: the one nobody sees coming Mapper-level tiers cache rows whose shape the schema defines, and schema changes go through migrations. An application entry caches a serialized model whose shape is defined by ordinary code. Deploy a version that adds a field, and old entries — written minutes ago by the previous version — deserialize into a model missing it, if they deserialize at all. Worse, during a rolling deploy both versions are writing entries under the same keys. A version segment in the key solves it completely and cheaply: the new code reads and writes a different key space, the old entries are simply never read again, and expiry cleans them up. The alternative — teaching the deserializer to tolerate both shapes — is compatibility code that has to be written, tested, and then remembered and removed later.