A per-user quota counter and a deduplication record live only in each region's own volatile tier while callers can be routed to either region - what breaks?

## Derived state and sole-copy state are different problems The case for **an independent tier per region** rests on a single premise: the entry is a locally derived view of something with another home, so two regions holding different values costs nothing. Sole-copy ephemeral state breaks that premise outright. A quota counter, a record marking a request as already handled, a lease on a resource, a session - these are not copies. **They are the state itself**, and the tier is the only place it exists. Run one tier per region and you have not distributed that state. You have created two of it. ## What each kind of sole-copy entry does wrong across regions - **Quota and rate counters.** Each region counts only what it saw. A user routed across both regions gets roughly the sum of the per-region allowances, and the overshoot grows with how evenly traffic is spread. Nothing detects it, because from each region's point of view the count is correct. - **Deduplication records.** A request marked handled in region A leaves no trace in region B. A retry - a client retry, a queue redelivery, an impatient user - that lands in the other region sees a key that was never written and does the work a second time. This is the expensive one: it is how a payment gets taken twice. - **Leases and claims.** Two regions can each hand out the same exclusive claim, because neither asked the other. Note that this is not the partition-time failure of one tier with two writable sides; it is the ordinary, healthy steady state of a design that never intended the two regions to talk. - **Sessions.** A user served in the other region is simply unknown there and is treated as unauthenticated, which is a visible outage for that user even though every component is healthy. The common shape: **the same mechanism produces an annoyance for derived entries and an incident for sole-copy state**, and nothing in the design distinguishes them. Only you can. ## Three repairs, and how to choose 1. **Give the state one home and route to it.** Pin the identity - user, account, resource - to a home region, and send requests that touch its sole-copy state there. This keeps the tier cheap and local for everything else, and its cost is that a home-region loss takes that state with it, which you must decide about in advance. 2. **Move that key class to a store authoritative across regions.** Pay the cross-region hop deliberately for the small volume of keys that need it - the claim, the deduplication record - while ordinary derived entries stay local. Here the hop buys correctness, not speed, so the arithmetic that rejected cross-region lookups elsewhere comes out the other way. 3. **Redefine the requirement as per-region.** Sometimes the honest answer is that per-region semantics are fine. A rate limit expressed as "per region" is a legitimate product decision if someone makes it knowingly. "Charged once" and "held by exactly one worker" never survive that treatment. | state | safe as one tier per region? | why | |---|---|---| | derived view of a stored row | yes | either region rebuilds it from the shared source | | rate counter | only if per-region limits are an accepted decision | independent counters sum | | deduplication record | no | the retry that lands elsewhere sees nothing | | lease or exclusive claim | no | two regions can each grant it | ## Where writes land decides more than it looks One fact usually settles repair 2 cheaply. If writes to the underlying system of record are accepted in only one region, then every write already crosses a region, and the correctness anchor can live on that same path at little extra cost - a uniqueness constraint or a conditional write in the durable engine, with the tier used only to keep the common case off it. If instead each region writes its own system of record, you do not have one shared truth to anchor to, and the sole-copy state has to be designed for explicitly rather than assumed into place. ## What varies across stores Do not assume a product-level way out. Some stores in this class offer copies propagated between regions, a few of them accepting writes in more than one region with machinery to make copies converge; others offer nothing. Even where it exists, converging two counters is not the same as enforcing one limit, and converging two claims is not the same as granting one. **Convergence makes copies agree eventually; exclusivity requires that only one grant ever happened.** Those are different guarantees, and the second is the one a claim needs.