Your service deletes a sign-off tuple then re-checks; how do you choose between demanding your own write is visible and taking a cheaper possibly-stale read?

## Why you get a choice at all A relation-tuple store is a replicated system serving an authorization question on the hot path of nearly every request. Always reading the freshest possible state would put a coordination cost on every check; never doing so would mean an engineer who was just granted authority cannot use it. So the store pushes the decision to the caller, per read. The mechanism is small. A write returns a **consistency token**: an opaque value naming the version of the store at which that write became visible. Note what this is not — it is not an access token, not a session identifier, and not a CSRF value. It is a watermark, and it is meaningless outside the store that issued it. ## The read modes | mode | what you get | what it costs | when to use it | |---|---|---|---| | cheapest recent snapshot | any sufficiently recent version | least latency, most cacheable | ordinary read traffic where a short window of staleness is acceptable | | at least as fresh as a token | a snapshot that includes the write that produced the token | a little more latency, less shared caching | the read that follows your own write, in the same flow | | fully fresh | the newest state the store can serve | most expensive and least available under load | rare, and usually a sign the token was not carried where it should have been | The middle mode is the one to reach for, because it asks for exactly the freshness you can justify — *my own write* — rather than for absolute freshness you cannot afford everywhere. ## The asymmetry that decides the policy Stale reads are not symmetrically harmful: - **After a grant**, a stale read denies someone who should be allowed. The engineer sees a refusal, retries, and it works. Annoying, self-healing, visible. - **After a revocation**, a stale read allows someone whose authority you removed. Nothing is visible to anyone. In a maintenance record system that is a sign-off entered by an engineer who was removed from the airframe's inspector list seconds earlier, and the record will not look wrong afterwards. So the rule is not *use the token everywhere*, it is *use it wherever a wrong answer is a wrong allow*. Revocation flows, privilege-reduction flows, and any read-back your own code performs immediately after its own write. ## Owning the lag in writing If you take the cheapest read, say how stale it can be. Real stores bound this — a snapshot window measured in seconds rather than minutes, often configurable — and the number is a property of your deployment, not a mystery. An answer that says *the revocation is immediate* without naming the window is wrong; an answer that says *the revoked engineer can still pass a check for up to the store's snapshot window, which for us is N seconds, and that is why the revocation endpoint reads with the token* is the one to give. ## Carrying the token is the real work The call is trivial. Getting the token to the next reader is not: 1. **Same request.** Trivial: hold it in a local variable across the write and the read-back. 2. **Same user's next request, different process.** The token has to live somewhere — most commonly stored beside the object it concerns, so any later read of that object can demand at least that freshness, rather than being pushed into the user's session where it will grow and go stale. 3. **Across an asynchronous hop.** A worker that processes a queued sign-off must receive the token in the message if its decision depends on a write the enqueuing request made. 4. **Across services.** A token is per-store; passing it between services is fine, but each hop needs a place to put it, and a token that is never used is just latency you paid for nothing. A common mistake is a single global watermark bumped on every write. It works, and it quietly converts every read into a fully-fresh read, which is the expensive mode wearing a disguise. ## What the enforcement point does when the read fails The store makes the decision; your endpoint enforces it. If a consistency-qualified read times out or the store is unavailable, the endpoint chooses — and for an authorization question the safe choice is to deny and surface a `403`, not to fall back to a cheaper read mode, because falling back is precisely the behaviour an attacker would want after a revocation. Log the failure as an availability event rather than as an access denial, so the two do not become indistinguishable in your dashboards. ## The review question For each write path in your service, ask: *if the next read of this object returns the state from just before this write, who is harmed and would anyone notice?* Every path where the answer is *someone gains authority they should not have, silently* carries the consistency token.