You are choosing which data across the estate must be encrypted by calling a central service on every operation — what decides where that line falls?

## The unit of the decision is a data class The question is almost never "should this service use a central encryption service". It is "which *kinds of value* in this estate are worth one network call per operation". Systems contain data of wildly different shapes, and a rule set at system granularity will be wrong for most of the fields inside it. ## Four questions that settle it 1. **How often is the value read?** A call on a write path that runs a few hundred times a second is a capacity question with a known answer. A call on a read path that runs on every page view multiplies the dependency by your traffic, and the usual escape — caching the plaintext — gives back much of what the arrangement bought. 2. **How big is it?** A per-operation service is built for fields and digests, not for bulk. Streaming a large document through it on every access is the wrong shape at any batch size. 3. **What is custody actually worth here?** For a value whose exposure ends the moment it is copied, custody buys a bounded window instead of a permanent capability. For a signing operation it buys more, because a forged artefact cannot be produced anywhere the service is not. For a value of low sensitivity it buys a round trip. 4. **What can the write path absorb?** Latency budget, and the fact that this path now depends at runtime on a system another team operates. How the workload behaves when that call does not return is its own design question, and it has to be answered before the standard is set, not after. ## Read shape dominates | Data class | Read shape | Fit | |---|---|---| | An applicant identifier read once when a case closes | rare, single field | Strong | | A stored handle read on each recurring charge | periodic, single field | Good | | A profile field rendered on every page view | hot, single field | Poor unless plaintext is cached, which erodes the benefit | | A scanned document retained for years | rare, but large | Poor — bulk does not belong on a per-operation service | | A signature over an outbound instruction | thousands a day | Strongest case in the table | ## Why signing is usually the stronger case Encryption protects data that, once copied, stays copied: an attacker with a stolen database and a compromised application gets what they can decrypt while their access lasts, and keeps whatever they already pulled. Signing is different in kind. An application that cannot hold the private key cannot produce a signature anywhere else, at any later time, under any circumstances — so a compromise yields only what the attacker can get the service to sign while they remain inside, and every artefact that exists corresponds to one request the service served. The rate at which signatures are needed is usually low, so the throughput objection barely applies. ## What standardising costs the estate - **Every adopting write path acquires the same runtime dependency**, which means the estate's availability now has a component it did not have before, and a single team's capacity planning becomes everyone's. - **A shared throughput and cost budget.** One team's bulk backfill is now another team's latency incident. - **A migration cost if the standard is wrong.** Values encrypted under a key that cannot be exported must be decrypted through the service and re-protected under whatever replaces it, at the service's throughput, while the application keeps running. That is a migration whose duration is a function of your data volume. - **A conversation every team must have** about what its path does when the call does not return — which is a separate subject, but one the standard forces onto everybody at once. ## The blanket rule and how it fails The rule that actually gets written is "every sensitive field goes through the service", and it fails in two directions at once. It drags hot read paths and bulk objects onto a per-operation service where they do not belong, producing latency problems that get solved by caching plaintext — which quietly returns the estate to holding what it was trying not to hold. And it encourages the belief that data on the far side of the rule is protected from everyone, when what custody buys is protection from an attacker who takes a *copy*, not from anyone the service will answer on the caller's behalf. The defensible version of the standard names data classes and read shapes, states which operations each class must perform remotely, and says plainly what the arrangement does not cover. An external review asking who could have produced this plaintext, and when, is answerable under it; a blanket rule with cached plaintext behind it is not.