Routing scope, failover and partitions
What this concept is
A progress token is meaningful only within its history and routing scope. The simulator has one stream and no leadership changes. Extending it to multiple shards or a promoted replica requires new rules rather than comparing every position as a global counter.
Why it matters here
A read guard can preserve a guarantee by refusing a read, but it cannot manufacture an eligible replica or recover lost writes. Availability and history compatibility remain explicit obligations of the routing and failover design.
Concrete example
A session requires prefix 3. f1 has applied 2, f2 has applied 1 and the leader is offline. The model cannot return a successful guarded read now. Calling one follower “new leader” would not make position 3 appear. A bounded wait may end in failure; silently returning prefix 2 changes the contract.
Common confusion / misconception
A larger numeric position on another timeline is not proof that it contains this session’s writes. Similarly, a token for shard A cannot order an unrelated write on shard B. Quorum intersection arithmetic alone does not supply a version-comparison, reconciliation or fencing protocol.
How to use it
For the original migration lab, label old and new ownership, snapshot boundary and change-capture position. Require evidence that new ownership includes the needed history before routing session reads there. Explain which component rejects a stale owner’s writes. Preserve the original crash/retry and no-double-counting tests; this read simulator is not their substitute.
Check yourself
If no replica meets the lower bound, what responses preserve the contract? What would need to be carried in a cross-shard session token, and why would that still not automatically establish an atomic snapshot?
Mini drill or application
Draw a two-shard dependency: a profile update on A followed by an activity event on B. Give one token per shard and identify the dependency that independent scalar tokens do not express. Then describe a failover that loses an acknowledged asynchronous write and state why a read guard can detect inability to serve but cannot restore it.
Read this only if stuck
Use DDIA on failover and partition routing. Consult PostgreSQL replication settings for operational retention and standby configuration questions. Consensus and formal consistency proofs remain later module work.