Replication prefixes and session read contracts
This required 22–32-hour package supplies the executable core of guided Lab 1: lessons and predictions 6–8, implementation and experiments 10–16, assessment and repair 6–8. Reuse its timeline and tests rather than repeat the lab. Original quorum/conflict, skewed partitioning, migration, routing and failover work remains required. Estimates await learner pilots; see the reconciled semester workload.
Prerequisite bridge
From Module 2, explain why replayed log prefixes determine visible state and why unrelated histories cannot share offsets blindly. From Semester 05, distinguish sending, receiving, applying and observing a reply. Here explicit simulator events replace wall-clock timing; no packet, disk or election behavior is simulated.
Learning sequence
- Receipt versus visible prefixes.
- Session high-water marks.
- Routing scope, failover and partitions.
- Prediction practice, runnable lab and all RP1–RP6 gates.
Download replica-session-contracts.zip. Python 3 standard library only. Implement starter.py using the README contract; run python3 -B check.py starter. Consult python3 -B check.py reference only for calibration after attempting.
Explicit model
One fixed leader creates a committed history. Two followers receive and apply contiguous prefixes separately. Reads either return a value and observed prefix, report blocked because the required prefix is not applied, or report unavailable. A missing key at an adequate prefix is a successful result, not a blocked request. A session merges successful write and read tokens by taking the maximum position in this one history.
All commit/apply actions on the leader are atomic abstract transitions. No durable disk, real database, packet transport, timeout scheduler, quorum, failover, split brain or multi-shard transaction is represented. The reference replays a Python list for each read, so timings do not estimate database performance.
Evidence and integration
Keep an event ledger: sequence number, event, leader commit position, follower received/applied positions, request token, response and next session token. Predict before executing. Preserve an unguarded stale read and its guarded blocked counterpart. Define a caller policy for blocked/unavailable: bounded waiting, routing to a verified eligible replica, or an explicit failure. Never silently weaken the requested guarantee.
The supplied checker covers 100 two-follower prefix states and 2,400 read decisions, token merging, invalid transitions and availability. Add three independent traces, including an overwrite and an unavailable leader. Complete the original partitioning and migration labs; a correct single-history read guard does not prove safe ownership transfer.