Why Did the Repair Disappear When Botie Read It Back?

A technician marks a job complete. One copy records the change, but the next screen reads a replica that has not received it yet. The update may still be safe in storage while the screen gives the user an older view.

Replication creates several copies; a consistency contract says what their readers may observe. We will first preserve one session’s known revision, then separate that promise from stronger global ordering.

Filter reachable replicas, require the session revision, and retain a wait result when no eligible copy is available.

wait

A primary can accept writes and send them to followers. Other systems permit several writers or require coordination among replicas before an operation completes. The replication topology alone does not tell us which acknowledgements count as success or where a subsequent read is allowed to go.

Ask what was acknowledged, which failures the durability promise covers, and what the chosen read mode returns. A successful write and a fresh read are related concerns with different contracts.

Do not infer a database’s behaviour from the label NoSQL.

Read-your-writes means a session does not read a state older than its own completed writes, within the system’s specified scope. Monotonic reads prevent that session from moving backwards after observing a newer state. Neither promise alone gives every user the same latest value.

Linearizability gives operations the appearance of taking effect at one instant between invocation and response, respecting real-time order. A read starting after a completed write must reflect that write or a later one for the object. Eventual consistency instead describes convergence once updates stop and communication succeeds; it is not a fixed staleness deadline.

Our version-floor model illustrates a session property on one totally ordered record, not a complete implementation of any distributed protocol.

The Python input contains replica IDs, visible revisions and reachable booleans. minimum is the greatest revision this session is required to preserve. We remove unreachable copies, then remove visible revisions below that floor.

Among eligible copies, the example chooses the highest visible revision and breaks ties by replica ID. If none qualify it returns wait. Real systems may use session tokens or route to a suitable leader rather than exposing revision numbers to the caller.

Selecting the maximum from a supplied list is not evidence that an unseen replica has no newer value.

replica = {"id":"west", "version":6, "reachable":True}
minimum = 7
print(replica["reachable"])
print(replica["version"] >= minimum)

True
False

If the replica with a completed update cannot communicate with the replica receiving the read, the reader cannot learn the update from that unavailable path. A service requiring the stronger ordering may stop or fail the affected read. An application permitting a stale result may return one with appropriate semantics.

CAP availability is a formal property that every request at a non-failing node eventually receives a valid response. It is not the same as an uptime percentage, and an error response is not a successful read of the specified register. When the network works, latency and coordination costs still matter, but CAP is not a general two-out-of-three purchasing checklist.

Choose per operation where the system permits it. A repair history screen and an exclusive stock reservation may need different contracts.

A read set and write set can intersect when their quorum sizes are chosen appropriately for a fixed replica set. That intersection is useful, but the protocol must also handle concurrent writes, version order, failed acknowledgements and recovery. Sloppy quorums that use replacement nodes change the intersection assumptions.

Cassandra exposes consistency levels for operations and has separate mechanisms for lightweight transactions. Treat each documented guarantee as scoped to its protocol and configuration. Counting two answers out of three cannot, by itself, prove linearizability.

The workshop intentionally avoids turning replica counts into a promise stronger than the model can establish.

DynamoDB documents eventually consistent reads as its default. Its tables and local secondary indexes also support strongly consistent reads, while global secondary indexes and streams do not provide that same read option. Global tables now have distinct multi-Region eventual and multi-Region strong consistency modes.

Review the selected mode and supported region/configuration requirements rather than transferring a statement about one path to another. A transaction, a table lookup and a secondary-index query can have different boundaries.

The source links document the current implementation. The local exercise does not contact DynamoDB.

A read can return a permitted older view, wait, fail, or fall back to another source. Decide which outcomes the screen can explain accurately. A bounded timeout may be necessary even when the formal contract permits waiting; timing out does not mean the remote write never happened.

For an optimistic edit, preserve the expected revision and check it atomically when writing. A stale screen should not silently overwrite another technician’s later repair. The next lesson uses that condition to protect a concrete stock reservation.

The changed workshop case restores connectivity without weakening the session’s revision requirement.

A freshness test should include the write receipt, subsequent reads, replica lag and a recovery path. Record which session and key each observation belongs to. A test that begins after every replica caught up cannot expose the disappearing-write experience.

Use the local model to reason about allowed routes, then use fault-aware integration tests against the chosen database to verify its real contract. Do not treat the Python function’s deterministic output as evidence about a live network.

We can now say exactly why a reachable replica may still be unsuitable for this read.