Two regions each run their own volatile tier over one shared system of record and the same key holds different values in each - why is that usually accepted?
answer
- derived, not authoritative
- no merge without a shared authority
- agreement would cost the hop back
- each entry's lifetime is the bound
- the premise fails for sole-copy state
basics
~20 sBoth values are locally derived views of one shared system of record, so neither is authoritative and there is nothing to merge. Making them agree would put a cross-region exchange back on the write path.
solid answer
~40 sThe two entries are not two edits to one truth; they are two independent derivations from the same underlying system of record, made at different moments by different traffic. Nothing is lost by their disagreeing, because either region can rebuild its own from the shared source. Merging them would require a cross-region conversation on every write, which is the cost the independent-tier design exists to avoid, and there is often nothing to merge with anyway - where the server only hands back opaque bytes, there is no semantic merge available at all. What bounds the disagreement is each entry's lifetime, not any agreement between the regions. The design stops being acceptable the moment a key holds state that is not a copy of anything - a claim, a quota, a deduplication record.
go deeper
Two regions each keeping their own copy of a derived entry will sometimes hold different values for the same key. That is expected when neither copy is the original.
Explain why no merge is needed: both entries come from one shared source, so either region can simply derive its own again. Then name what bounds the disagreement - the lifetime on each entry.
Argue the trade rather than asserting a preference: agreement between regional tiers costs a cross-region write path, and the problem it solves is a derived value being briefly stale. Say clearly where the argument stops holding.
Decide which surfaces may show a user two different answers from two regions, and write that down. It is cheaper to route a user consistently than to make every regional tier agree on every key.
## The two tiers are not two copies of one thing When a design runs **an independent tier per region**, each region's tier is filled by that region's own traffic from the shared system of record. The same key can then hold a different value in each region for an ordinary reason: region A derived its entry at one moment, region B derived its own at another, and the underlying row changed in between. That is not a conflict in the usual sense. A conflict is two writes to one authoritative thing; this is **two derivations of a thing whose authority lives somewhere else entirely**. The practical consequence is that neither value needs to win. Either region can throw its entry away and derive it again from the system of record, which is exactly what happens the next time the entry's lifetime elapses or the tier reclaims the memory. ## Why nobody merges them Three reasons, and they stack: - **There is nothing to merge.** Merging implies two contributions to one value. Here both entries are approximations of a value held elsewhere; the correct resolution is not a merge but a re-derivation from the source. - **A merge would cost the hop.** Any agreement between the tiers means a cross-region exchange on the write path, which is what the per-region design was chosen to avoid in the first place. Buying consistency between two derived copies at that price is paying an expensive bill for a cheap problem. - **The store may offer no merge semantics at all.** This matters more than it looks. Where the server interprets the stored value, a merge is at least conceivable; where the server holds **opaque bytes** it only hands back, there is no partial update and no semantic merge available, and the whole question dissolves. ## What actually bounds the disagreement Not agreement between the regions - **the lifetime attached to each entry**, plus whatever causes each region to re-derive. Two independent tiers with short lifetimes disagree for a short window; the same tiers with long lifetimes disagree for a long one. That is the knob, and it is a local knob in each region. Sizing it is a judgment about how stale a derived answer is allowed to be in the region that serves it, not about the other region at all. ## The alternative, and what it buys | posture | what the regions share | what it costs | where it is right | |---|---|---|---| | independent tier per region | only the system of record | the underlying work is paid once per region, and the two disagree | derived entries that either region can rebuild | | copies propagated between regions | the tier's own contents | a cross-region path on the write side, plus whatever the product's propagation actually guarantees | state that must be the same everywhere, or a region that cannot rebuild locally | Products in this class differ sharply on whether the second row is even available. Some offer copies propagated between regions, a few of them accepting writes in more than one region with machinery to make the copies converge; others offer one-way propagation; others offer nothing at all. Treat availability and guarantees as things to check, never to assume. ## When "accepted" stops being true The argument above rests entirely on one premise: **the entry is a copy of something that has another home.** Remove that premise and every sentence above fails. State that lives only in a region's tier - a claim on a resource, a quota counter, a record marking a request as already handled - cannot be regionally independent without being wrong, because two independent copies of it are simply two different facts about one user. That case needs a single home and is a different design conversation. A second boundary is worth naming: some derived entries are things a user is looking directly at. A user whose request lands in region A and then in region B sees two different answers to the same question, seconds apart, with no failure anywhere. If that is unacceptable for a particular surface, the repair is usually to route that user consistently rather than to make the tiers agree. ## How to say it in an interview Name the premise first - these are derived entries with a shared authoritative source - then the three reasons nobody merges, then the bound (each entry's lifetime), then the exception (state with no other home). A candidate who goes straight to "we should keep them consistent" has skipped the question of whether consistency between two derived copies is worth a cross-region write path, which is the actual decision.
- What actually bounds how long the two regions can disagree about one key?The lifetime attached to each entry, and whatever else makes a region re-derive it - not any exchange between the regions. Each tier re-reads the shared system of record on its own schedule, so the window is a local choice made twice. Shortening it costs more underlying work in that region and buys a narrower disagreement.
- A user's two requests land in different regions seconds apart and show different answers. Is that the tiers' problem?It is the routing's problem more often than the tiers'. Making two independent tiers agree costs a cross-region write path for every key; pinning that user's session to one region costs nothing extra and fixes the symptom they actually see. Reserve the expensive repair for state that genuinely must be identical everywhere.
saying these in an interview costs you the question
- Calls the difference a conflict needing a winner
- Proposes keeping both regions' tiers in step by default
- Assumes every store can merge two divergent values
- Thinks the regions converge on their own without a shared source
- Cannot say what bounds how long they disagree
- Applies the same reasoning to state with no other home