Consistency Models — Linearizable, Sequential, Eventual

Learning goal: Compare ordering, session and convergence guarantees using operation histories, then choose a scoped contract for carts, leaderboards and ledgers. The useful goal is not memorizing a false six-rung ladder.

Why this session exists

After saving a profile, a user refreshes and sees the old biography. A leaderboard drops from 42 to 41. Two buyers both reserve the last item. These symptoms may arise from different contracts: missing read-your-writes, a regressing replica version, or a non-atomic read/modify/write sequence. They need different fixes. A single-node database can also exhibit surprising transaction isolation; a B-tree or one machine is not a consistency guarantee by itself.

You will be able to

• Define linearizability, sequential consistency, causality, read-your-writes, monotonic reads and eventual convergence without inventing a total ordering among them.
• Draw histories that distinguish real-time ordering, program order and causal dependencies.
• Identify stale observations, version regression and lost updates, including when a decreasing numeric value is legitimate.
• Compare documented database operations and select the weakest contract that actually preserves the feature's invariant.
• Explain why a finite safety checker does not prove eventual delivery or deployed-system correctness.

Prerequisites

• S070 · CAP & PACELC — the trade space this session picks a point in.
• S071 · Replication — you must know what a follower is before you can reason about what it lags by.
• S042 · Transactions & ACID — isolation and atomicity apply to transaction scope on one or many nodes.

Preparation and pacing

Use the intuition, diagrams, offline history checker, failure analysis and recall as separate passes. The original 90-minute plan and 5/15/25/15/10-minute phase labels are planning suggestions, not measured completion times; preparation and deeper exercises can take longer. This is part of the 130-session learning route, not a promise that product documentation stays evergreen.

Optional original discovery pointers

These exact original destinations preserve the preparation route. Video titles/creator labels below are historical finding labels, not verified attribution: the videos were not watched, and their content, duration and availability were not checked in this review. Prior superlatives and guaranteed viewing times are not endorsed.

• “Top 7 Most-Used Distributed System Patterns” — formerly labelled ByteByteGo: optional visual orientation to distributed patterns, not evidence for a six-rung consistency ladder.
• “Distributed Consensus & Consistency” — formerly labelled MIT 6.824: optional formal linearizability and Raft background; no claim that a particular lecturer or first 40 minutes covers those topics has been verified.
• Jepsen / Kyle Kingsbury consistency search: a search, not an identified recording or a verified vendor-failure demonstration.
• Jepsen consistency-model map: optional model relationships to compare with the scoped histories here; not a complete governing specification for every database API.
• “Eventually Consistent” historical essay: optional availability and convergence context. An essay about Dynamo is not proof of modern DynamoDB or Cassandra defaults, or of who popularized a term.
• Cosmos DB consistency-level documentation: a product-specific menu of bundled guarantees. It does not establish that Cosmos is the only configurable cloud database or that every per-request override can strengthen the account default.

(a) Intuition · 5 min

A group-chat reply should not appear before the message it answers. That is a dependency-ordering requirement. A completed stock reservation must be visible to a later competing reservation. That is an ordering plus atomic-mutation requirement. Two independent messages can often appear in different orders without harm.

Linearizability does not mean every phone displays a message at the same instant. It means operations can be explained as taking effect one at a time at points inside their call/return intervals, preserving the order of nonoverlapping operations. Screens, caches, transport and application transactions may add other behavior outside that object contract.

The six-rung ladder — why it needs a partial-order correction

Linearizability places each operation at some point between invocation and response and preserves real-time order. Sequential consistency preserves each client's program order but need not preserve that cross-client real-time order. Causal consistency preserves cause-before-effect dependencies while allowing concurrent operations to appear in different orders. Eventual convergence says replicas converge when updates stop and communication succeeds under the model; it does not specify a fixed delay.

Read-your-writes and monotonic reads are session guarantees. Bounded staleness constrains lag in versions or time. These are not all rungs of one universal six-item ladder: vendor spectra combine particular guarantees and scopes. Linearizability of individual keys does not establish serializable multi-key transactions. Serializable transactions do not necessarily respect external real-time order; strict serializability combines those properties. Draw histories with call/return intervals and state the object/transaction scope before selecting a label. A wall-clock timestamp cannot manufacture an ordering guarantee when clocks skew.

A quick history — where the models came from

Lamport's 1979 sequential consistency defines behavior equivalent to an interleaving that preserves each processor's program order. Herlihy and Wing's 1990 linearizability additionally places each operation between invocation and response; it applies to concurrent objects, not only databases. The 2007 Dynamo paper illustrates availability-oriented version reconciliation; it is not a claim about today's DynamoDB defaults. MongoDB's documented causal sessions and Cosmos DB's session level are concrete scoped API contracts. The 2002 CAP proof explains why the strongest ordering cannot coexist with availability at every nonfailed node in every partitioned execution.

The ladder as a diagram

The original six-item chain was misleading: read-your-writes does not by itself imply monotonic reads, and bounded staleness is a separate axis. This diagram separates dimensions rather than inventing an implication between them.

For a single register initially zero, let A complete write(1), then B invoke read() and return zero. That history is not linearizable. It may be sequentially consistent if a global order places B's read before A's write while preserving each client's program order. If B first read 1 and then read 0, monotonic reads fail. These are different tests, not synonyms for “the replicas look synchronized.”

The timing anomaly that separates the top three rungs

Test the promises with a tiny history: one write completes before a different client begins its read. That acknowledgment gives you a real-time boundary against which to judge the returned value.

Returning the old value after that boundary rules out linearizability for this history. A weaker model may permit the observation, but eventual convergence alone does not put a deadline on when the new value will become visible.

Causal dependency trace

This is a separate obligation from cross-client wall-clock freshness. B observes message M before creating reply R, so R depends on M. C must not observe the reply without the message in a causally consistent view; unrelated concurrent messages need not share one universal order.

A causal view is not one global interleaving

Let independent writers perform Wx(1) and Wy(1) on initially zero registers. Reader C sees x=1 then y=0; reader D sees y=1 then x=0. With no message/dependency between the writers, these two views can be causally consistent: each reader has seen a different concurrent write. No sequential order explains both. C requires Wx < C.Rx < C.Ry < Wy; D requires Wy < D.Ry < D.Rx < Wx, producing a cycle. This is a two-register counterexample, not a test the single-register checker below can accept as input.

Now let B first read message M and then write reply R. The read-from edge and B's program order make M a dependency of R, transitively. A view exposing R must make M available; this is not a promise that a filtered UI must literally render both messages. Read-your-writes carries your own prior writes; monotonic reads prevents your observed version/dependency frontier from regressing. Monotonic writes preserves a session's write order. Writes-follow-reads makes a later write depend on the writes that session has observed. Carry the dependency token across the actual client/session boundary; load-balancer stickiness alone is not a proof through failover, rollback or cross-device use.

For a finite set of append-only events, dependency closure is inspectable:

from itertools import combinations
 
dependencies = {'M': set(), 'R': {'M'}, 'X': set()}
def closed_view(visible, deps):
    visible = set(visible)
    return visible <= deps.keys() and all(deps[e] <= visible for e in visible)
 
# Every included event must include its immediate dependencies;
# applying the rule to all included events also enforces transitive closure.
assert not closed_view({'R'}, dependencies)
assert closed_view({'M', 'R'}, dependencies)
assert closed_view({'X'}, dependencies)
views = [set(v) for k in range(4) for v in combinations(dependencies, k)]
assert sum(closed_view(v, dependencies) for v in views) == 6

This checks eight possible views of three immutable event IDs. It does not model register overwrites, causal broadcast delivery, session-token APIs or eventual progress. The cycle argument above and dependency-closure fixture test different obligations.

The four decisions inside "which consistency model?"

1. Which object? One register, one document, one partition or a multi-key transaction? Individually linearizable read and write operations do not make read; compute; write atomic. Two clients can both read stock=1 and both write stock=0, selling two units while each primitive remains linearizable.
2. Which operations? Are strong reads opt-in? Do write acknowledgments mean accepted, durable, quorum-committed or applied? Are conditional mutations supported? A stale cache can weaken what users observe even when the database itself is strong.
3. Which geography and failure domain? Replicas can share a zone, span zones or span regions. If a required message traverses an 80 ms round-trip link, that dependency adds latency. That is an assumption-based calculation, not a universal 200 ms lower bound for all distributed reads.
4. Which fault and progress conditions? A minority may reject reads and writes needing a quorum. Stale reads may continue but must be labelled as such. Neither a timeout nor a green process health check specifies whether the business operation committed.

Layers where each model shows up

• Application: defines invariants and carries session/dependency tokens. A client-side cache must honor their freshness requirements.
• SDK: requests ConsistentRead=true, a MongoDB read/write concern, or Cassandra's ordinary versus serial consistency. Different knobs do not imply equivalent contracts.
• Router: selects a replica that can satisfy the required position or authority; “nearest” and “primary” are destinations, not proofs.
• Protocol: elections, log commitment and read validation jointly matter. A Raft-backed system can deliberately expose stale reads; an asynchronous log requires repair/progress to converge.
• Storage and transactions: durability, locking, MVCC and transaction isolation govern local behavior. LSM and B-tree describe data organization, not automatically linearizable APIs. Two-phase commit coordinates atomic commit; it is not a synonym for consensus or serializable isolation.

Comparing three real systems side by side

Spanner: its default serializable transactions provide external consistency, including real-time transaction ordering. TrueTime supports timestamp assignment; replication, commit coordination and commit wait still matter. The current documentation also describes repeatable-read isolation, so explicitly name the mode rather than calling every possible transaction strict-serializable. No fixed 7 ms uncertainty or 50–200 ms latency promise is assumed here.

DynamoDB: table and local-secondary-index reads can request strong consistency using ConsistentRead=true; GSIs and streams are eventually consistent. The documented strong response reflects successful prior writes; it is not a documented promise to route to “the primary in one AZ.” Eventual reads cost half as much on the same size basis. Read consistency does not make separate reads and writes one atomic update; use conditional mutations or transactions for the applicable invariant. Global tables now document MREC and MRSC as distinct modes, not one timeless AP classification.

Cassandra 4.1: ordinary read/write consistency levels select response requirements, and timestamp-based reconciliation is distinct from its lightweight transactions' linearizable conditional-operation contract. A QUORUM request cannot complete on just any isolated replica. Fixed R+W>N ensures intersection, not a general real-time history proof; failed or concurrent writes and sloppy membership assumptions matter.

For session guarantees, MongoDB documents the combination of causally consistent sessions, majority reads and majority writes for all four guarantees with durability: read-your-writes, monotonic reads, monotonic writes and writes-follow-reads. Cosmos DB's five-level spectrum is a specific bundled product contract, not a theorem that read-your-writes implies monotonic reads everywhere.

The mental model to hold

Write the forbidden history before selecting a database. Ordering is a safety question: no bad finite prefix should be observable. Eventual convergence is a progress question: after updates stop and required communication/repair succeeds, replicas agree. An arbitrary delay is not a deadline. A finite trace with no late reads cannot certify eventual consistency.

Why the session guarantees are not a ladder. A client that makes no writes can read version 2 and then version 1: read-your-writes is vacuously satisfied, but monotonic reads fails. A client can write version 2 and then repeatedly read version 1: monotonic reads holds for its identical observations, but read-your-writes fails. Convergence does not imply either session property during the convergence window. Bounded staleness can still permit version regression within its permitted lag unless paired with ordering guarantees.

Causality versus sequential order. Suppose A writes message, B reads it and writes reply. A causally consistent history must not expose that reply without its dependency. Independent writes x=1 and y=1 may be seen in different orders by different clients under causal consistency. A sequentially consistent history requires one legal global order preserving all clients' program order. Linearizability additionally respects operation nonoverlap across clients. Different scopes or APIs must be compared under the same object specification before asserting implications.

Coordination costs, without a false lower bound. A linearizable reader needs an authority/state argument that rules out missing a prior completed write. A protocol may establish this through a current-leader quorum check, a properly bounded lease or other verified mechanism. It need not perform a new quorum round trip on every read, and the responding node need not learn the outcome of every concurrent write. The linearization point can precede a concurrent write. Distance, contention, batching and lease assumptions determine cost; a clock alone cannot confer write authority.

Convergence is not preservation of every update. LWW can converge while discarding an assignment. CRDTs merge under their specified algebra and delivery assumptions; they do not preserve arbitrary business intent or automatically enforce uniqueness, authorization or no-overdraft rules. A deterministic winner can be consistent but wrong for the product.

Inventory, compensation and escrow

For stock=1, two read/compute/write clients can both observe 1. Replacing the read with a linearizable read does not prevent both from proceeding before either writes. An atomic conditional decrement, such as “decrement iff stock is positive,” allows at most one success within its supported transaction/failover contract. That is the required safety invariant; availability may be sacrificed on an isolated minority.

An optimistic sales workflow can instead allow temporary overcommit and later cancel/refund. This is a different business promise, not eventual consistency eventually fixing the original no-oversell invariant. It needs idempotent refunds, an owner for unresolved payments, and a durable audit trail. Throughput remains finite and downstream outages still matter.

Escrow splits ten units into six rights in A and four in B. Local decrements can sell at most ten in total without cross-region communication, provided rights cannot be duplicated and transfers revoke old rights before granting new ones. If A sells all six while B has four left, A must refuse/wait for a safe transfer; it cannot keep promising availability for arbitrary stock requests. This preserves a specific invariant without implementing an always-available linearizable global stock register.

Workload choices and actual anomalies

• Cart/profile: read-your-writes plus monotonic reads across the session; define merges across devices. An absent token is not silently the same session.
• Leaderboard/view counter: eventual aggregation may be acceptable with an explicit freshness target. Counts can legitimately decrease after an unlike, moderation or correction. A 42→41 display proves a monotonic-read violation only if the later response came from an older version, not merely a smaller value.
• Ledger: atomic transactions and constraints for balances, durable idempotency for retries, and a stated isolation/real-time contract. External card effects require their own protocol; database linearizability does not prevent every double charge.
• Chat: causal message/reply visibility plus a chosen per-conversation ordering and delivery contract. Presence may be weaker. Not every direct message needs one global ordering across all conversations.
• Food delivery: accept stale rider locations with timestamps and expiry; preserve monotonic order-state versions; revalidate price/availability at checkout rather than treating a cached menu as authority.

(c) Hands-on · 25 min

Use a small exhaustive single-register safety checker, not wall-clock sleeps. All operations below complete; clients issue operations sequentially; the register initially contains 0. The checker searches possible serial orders, constraining either real-time nonoverlap or per-client order. It handles overlapping writes correctly, unlike choosing only the last write whose response preceded a read. Its factorial worst case is intentionally bounded to eight operations; it is not a production history checker.

from dataclasses import dataclass
 
@dataclass(frozen=True)
class Op:
    client: str
    kind: str
    value: int
    call: int
    ret: int
 
def legal(history, real_time=True):
    assert len(history) <= 8
    assert all(o.kind in ('R', 'W') and o.call < o.ret for o in history)
    # Each client is sequential; interval endpoints are unique in these fixtures.
    for a in history:
        for b in history:
            if a is not b and a.client == b.client:
                assert a.ret < b.call or b.ret < a.call
    predecessors = []
    for b in history:
        predecessors.append({i for i, a in enumerate(history)
                             if a.ret < b.call and
                             (real_time or a.client == b.client)})
    def search(done, value):
        if len(done) == len(history):
            return True
        for i, op in enumerate(history):
            if i in done or not predecessors[i] <= done:
                continue
            if op.kind == 'R' and op.value != value:
                continue
            if search(done | {i}, op.value if op.kind == 'W' else value):
                return True
        return False
    return search(set(), 0)
 
stale = [Op('A', 'W', 1, 0, 10), Op('B', 'R', 0, 20, 30)]
assert not legal(stale)
assert legal(stale, real_time=False)  # B's read can precede A's write
 
# The read overlaps the write and is allowed to see its new value.
overlap = [Op('A', 'W', 1, 0, 30), Op('B', 'R', 1, 10, 20)]
assert legal(overlap)
assert legal([Op('A', 'W', 1, 0, 30), Op('B', 'R', 0, 10, 20)])
 
regression = [Op('A', 'W', 1, 0, 5), Op('A', 'W', 2, 6, 10),
              Op('B', 'R', 2, 11, 12), Op('B', 'R', 1, 13, 14)]
assert not legal(regression, real_time=False)
 
# Session checks use logical versions on ONE totally ordered history.
# A newer version may have a smaller business value (e.g. an unlike).
def session_checks(events):
    own, seen = {}, {}
    ryw, monotonic = True, True
    for client, key, kind, version in events:
        pair = (client, key)
        if kind == 'W':
            own[pair] = max(own.get(pair, 0), version)
        else:
            ryw &= version >= own.get(pair, 0)
            monotonic &= version >= seen.get(pair, 0)
            seen[pair] = max(seen.get(pair, 0), version)
    return ryw, monotonic
 
assert session_checks([('A', 'x', 'R', 2), ('A', 'x', 'R', 1)]) == (True, False)
assert session_checks([('A', 'x', 'W', 2), ('A', 'x', 'R', 1)]) == (False, True)
assert session_checks([('A', 'x', 'W', 1), ('A', 'x', 'R', 2)]) == (True, True)
print('stale: linearizable=False, sequential=True')
print('overlap: either old or new is legal; regression is not sequential')
print('session guarantees are independent in these fixtures')

What each block does

predecessors expresses the required order, then search explores only topological orders that obey the register specification. A read must match the state at its chosen position, not the latest response timestamp. The overlapping-write example is a positive control: rejecting it would confuse linearizability with a stronger, incorrect “only completed writes may be read” rule.

The session checker tracks logical versions per client and key. It permits another client's newer overwrite after your own write, rather than requiring equal values forever. That checker assumes a single ordered history; concurrent branches need dependency/version-vector semantics rather than comparing arbitrary scalar timestamps. It is not a checker for all causal systems.

Sequential-consistency exercise: A writes 1 then 2. B reads 2 then 1; there are no further writes. Is there any legal order? Answer: no. Program order requires W1 before W2 and B's R2 before R1; R2 must follow W2, leaving no W1 after R2 to explain R1. Independent network timers can reorder deliveries even from one source; a single origin alone does not guarantee FIFO delivery.

Convergence exercise: replicas start at (version=0,value=0). Deliver version 1 only to A, then version 2 to A and B. Later deliver the delayed version 1 to B. Arrival-order overwrite leaves B at 1 while A is 2; stopping new writes does not fix that by itself. Answer: a version-aware apply rule retaining the highest version on this single-writer log leaves both at 2 after all messages arrive. This demonstrates a finite schedule. No finite waiting period proves convergence under all future failures, and a checker with no reads after its deadline should report insufficient observations, not success.

(d) Production reality · 15 min

An audit needs both successful and failed histories. Record operation IDs, keys, invocation and completion intervals, returned values/versions, errors and indeterminate timeouts. A timeout can mean “committed but acknowledgment lost”; silently treating it as aborted invalidates the history analysis. The bounded checker above deliberately excludes pending/indeterminate operations, multi-key transactions and Byzantine failures.

A deployment test should inject the specific failure it claims to tolerate: isolated minority, slow replica, leader pause, client retry, or regional loss. Verify forbidden histories as well as recovery latency. Source-backed conceptual understanding does not require running that deployment, but a deployment's guarantee cannot be proved by our few in-memory fixtures.

Historical incident pointers, not reproduced incidents

The original GitHub October 2018 incident, Jepsen MongoDB 4.2.6 analysis and Dynamo 2007 paper remain discovery pointers for failover, acknowledged-write loss and shopping-cart reconciliation respectively. Their original Oracle/Black-Friday narrative, default-setting allegations and exact outage consequences are not freshly verified here. The general mechanism is retained above: acknowledgements, replica authority, durability and application invariants must be checked independently; “availability wins for everything except money” is not a valid universal rule.

Where this shows up in the rest of the plan

Replication determines what replicas have applied; sharding determines which objects share an authority; queues adds retry/effect atomicity; multi-region identifies the fault domain and recovery contract. Transactions and isolation revisit transaction scope, and caching revisits TTL, read-through and write-through freshness rather than assuming every cache has one fixed model. For the original Twitter-style design-review connection, compare timeline freshness with direct-message dependencies in a newsfeed design; neither feature's name determines its consistency contract. The historical session numbers for those topics were mismatched, not alternate API guarantees.

(e) Recall + stretch · 10 min

1. Can you rank the six names in one chain? No. Under the same register model, linearizability strengthens sequential order with real-time constraints. Causality preserves dependencies rather than every independent order. Read-your-writes and monotonic reads are independent session properties, and eventual convergence is a progress requirement.
2. Does 42→41 prove stale data? No; it may be a legitimate newer unlike. Inspect versions and allowed operations before naming the anomaly.
3. Does a strong read solve a lost increment? No. Two clients can both read 0 then both write 1. Atomic increment, correctly scoped CAS with retries, or a suitable counter CRDT changes the mutation semantics.
4. Why does Spanner not violate CAP? It can stop operations unable to preserve its contract during a partition. TrueTime is one protocol ingredient, not unlimited availability or zero network delay.
5. Can a Cosmos DB read strengthen the account default? Traditional ConsistencyLevel overrides only relax it. The documentation checked on 2026-10-07 also describes preview ReadConsistencyStrategy (Java SDK v4.69+, .NET SDK v3.46+, direct mode only), which permits supported stronger per-read strategies. Name the API, preview status, strategy scope and write-durability boundary instead of asserting either blanket answer.
6. What is the cost argument against “strong everywhere”? Use measured requirements, not folklore. In a hypothetical 100 ms end-to-end budget, three sequential 40 ms dependencies already consume 120 ms before rendering. Weaken an observation only if its invariant tolerates that, or reduce round trips by redesign. This is arithmetic, not a universal database benchmark.
7. What makes a cross-shard transaction different? It may need atomic commit across participants plus isolation and replicated durability. Two-phase commit alone is not consensus, and a saga offers compensations rather than the same atomicity. No fixed 10–100× slowdown follows.

Additional original recall answers

• What distinguishes sequential from linearizable? Both require a legal common order under the specified object model; linearizability additionally respects nonoverlapping calls across clients. An overlapping write can explain a read even before that write returns.
• Which DynamoDB flag and cost? ConsistentRead=true requests a strong read for supported table/LSI operations; eventual reads cost half as much on the same size basis. GSIs/streams do not support that strong-read option. Do not infer a specific leader/AZ routing topology from this API contract.
• What prevents an old biography after your edit? Read-your-writes in the same scoped session, with its token/dependency passed correctly. A legitimate newer overwrite may still change the value. Session consistency need not expose your exact value forever.
• What happens to Cassandra writes across a partition? Only requests whose configured consistency level can be satisfied succeed. Ordinary mutations reconcile by timestamps, including deletes; a timestamp can come from the client or coordinator clock. This is not business-event ordering, and no unverified node-ID tie-break is assumed. Repair/delivery is still needed. LWT conditional operations use a distinct Paxos-backed contract; arbitrary ordinary writes are not automatically protected by it.
• Food delivery stretch: rider locations can tolerate declared staleness with expiry; order transitions need monotonic versions and validated allowed transitions; payments need atomic invariants and idempotency beyond read freshness; cached menus must be revalidated for an authoritative checkout price. Choose explicit freshness targets rather than inheriting arbitrary one-second/60-second limits.

Explain-out-loud test

Teach the stale/overlap histories, the two independent session counterexamples and the ten-unit escrow example. Then design the cart, leaderboard and ledger contracts above, saying which operation rejects during a partition and what retry is safe. A complete answer names the scope and invariant, not just “money strong, likes eventual.”

Continue with consensus for replicated-log mechanisms. Learning plan.

Sources and review boundary

Current lesson reviewed 2026-10-10. Primary snapshots from 2026-10-07/08 were reused after raw/canonical/quotation verification; Cassandra 4.1 reconciliation documentation was retrieved on 2026-10-10. No claim that every mutable URL was fetched again is intended; mutable documentation is bound to saved source hashes in the accompanying claim evidence. Numerical examples are explicit teaching assumptions. The bounded Python examples were run locally; no cloud/distributed deployment, PostgreSQL cluster, broker, object store, load benchmark or regional drill was executed. Compilation and diagram parsing do not establish deployed-system correctness.

• Linear Paper — Linearizable operations take effect within their own call/return intervals.

• Lamport 1979, How to Make a Multiprocessor Computer That Correctly Executes Multiprocess Programs — Sequential consistency preserves per-client program order in a legal common sequential history.

• Gilbert and Lynch CAP proof, 2002 — CAP excludes simultaneous availability and atomic consistency in the asynchronous partition model.

• Mongo Causal — MongoDB durable causal-session guarantees require the documented majority read/write combination.

• Azure Cosmos DB consistency levels — Cosmos session reads carry a token and require a sufficiently advanced replica.

• Cosmos Override — Traditional Cosmos overrides and the newer ReadConsistencyStrategy have different strengthening rules.; The newer read-strategy feature is preview and direct-mode-only.

• Dynamo Read — DynamoDB strong reads have table/LSI scope and do not cover GSIs/streams.; DynamoDB eventual reads cost half as much on the same read-size basis.

• Dynamo Global — Current DynamoDB global tables distinguish MREC and MRSC.

• Cass Guarantees — Cassandra lightweight transactions have a different consistency contract from ordinary writes.

• Spanner — Spanner external consistency applies to its default/serializable isolation contract.

• Spanner Paper — Spanner replication uses Paxos groups in the 2012 design.; Spanner commit wait is part of its external-order protocol.

• Cassandra 4.1 Dynamo architecture — mutation timestamps, per-column reconciliation and repair; not application causality.