Replication & Consistency Models

Sync vs async is orthogonal: sync = follower acks before commit (durability, +RTT per write, follower outage blocks writes) · async = fast, but leader death loses the un-shipped tail · semi-sync = exactly one sync follower as the durable copy — the pragmatic default.

Fast trackThese three anomalies are the source of the "user saved their profile and it vanished" bug class. Read fully; run the sim.

Async lag is normally milliseconds and occasionally minutes (bulk load, follower restart, network blip). "Eventually consistent" is a fine property until a user sits inside the window:

• Read-your-writes violation — user updates their profile (→ leader), next page reads a follower that hasn't caught up: their edit "vanished". Fixes: read own data from the leader; or session-sticky reads; or client sends last-seen LSN/timestamp and replicas serve only if caught up.
• Non-monotonic reads — successive reads hit differently-lagged replicas: a comment appears, then disappears. Time runs backwards. Fix: pin a session to one replica (consistent-hash users → replicas).
• Consistent-prefix violation — causally ordered writes (question → answer) observed out of order via differently-lagged partitions. Fix: keep causal chains in one partition, or causal-consistency machinery.

Models are contracts about what reads may observe, ordered strongest → weakest. Stronger = fewer surprises = more coordination = more latency and less availability. Tap each for its cost:

Leaderless systems write to W of N replicas and read from R. If W + R > N, read and write sets must overlap, so a read touches at least one replica with the newest acknowledged write. Play with it:

Now the part that fails design reviews. Overlap ≠ linearizability:

• Partial-write races: a write lands on replica 1 but not yet 2–3; a concurrent read at R=2 from {1,2} vs another from {2,3} — two readers, two answers, both "valid quorum reads". Ordering concurrent ops needs consensus, not arithmetic.
• Sloppy quorums (Dynamo-style, for availability): during faults, writes accept on substitute nodes outside the home set, with hinted handoff shipping them home later. Availability goes up; the overlap guarantee quietly disappears until handoff completes.
• Read repair & anti-entropy are the convergence machinery — stale replicas get fixed on read or by background sync; they set how long "eventual" lasts.

• Last-write-wins: pick by timestamp. Cheap, deterministic, and lossy — with clock skew, "last" is a lie. Acceptable for resume points; unacceptable for anything counted or owned.
• Vector clocks / versions: track causality; if versions are concurrent, surface both to a merge function. Correct, but pushes complexity into the application.
• CRDTs: counters, sets, registers with mathematically convergent merges. A distributed concurrent-streams counter as a PN-Counter merges cleanly after the Module 03 partition — the principled version of "take the max and reconcile."

public class ReplicaRoutingDataSource extends AbstractRoutingDataSource {
  @Override protected Object determineCurrentLookupKey() {
    if (ConsistencyContext.leaderRequired())        // read-your-writes paths set this
      return "leader";
    return TransactionSynchronizationManager
        .isCurrentTransactionReadOnly() ? "replica" : "leader";
  }
}

// entitlement check right after purchase — a READ that must hit the leader
public Entitlement verifyPostPurchase(String userId, String contentId) {
  try (var scope = ConsistencyContext.requireLeader()) {  // ThreadLocal / ScopedValue
    return entitlementRepo.find(userId, contentId);       // linearizable-enough: leader read
  }
}

Wrap the target in LazyConnectionDataSourceProxy so the routing decision happens after @Transactional attributes are known. Equivalent knobs elsewhere: Mongo readPreference=primary per-operation; Redis WAIT; JDBC readOnly hints on Aurora endpoints.

Fast trackStep 3 alone (~40 min) delivers the module's core scar tissue: a reproduced read-your-writes violation and its fix.

Self-check