Consistency

Software Engineering / 21 Sep 2026 / 7 min read

Version Vectors Separate Causality from Concurrency

Version Vectors Separate Causality from Concurrency Replicated data can receive writes at several nodes while communication between those nodes is delayed. When two versions meet later, a store has to decide whether one descends from the other or whether both were created independently. A wall-clock timestamp gives a total-looking order, but clock order is not causal order. Two replicas can write during a partition, and whichever timestamp happens to be larger does not make that write a descendant of the other.

Software Engineering Distributed Systems

Software Engineering / 12 Sep 2026 / 8 min read

Vector Clocks and the Shape of Concurrent State

A single version number can state that one value came after another only when every update participates in the same ordered sequence. Replicated state breaks that assumption as soon as independent writers can accept changes without first agreeing on one global next version. Two replicas can each move forward from the same ancestor. Calling one state version 8 and the other version 9 creates an order, but that order may describe the numbering scheme rather than the causal relation between the writes. Vector clocks represent a different fact: which update history a state has observed.

Software Engineering Distributed Systems

Software Engineering / 12 Sep 2026 / 8 min read

Fencing Tokens for Expiring Distributed Leases

A lease can expire while its holder is still running. That single property separates a distributed lease from an ordinary in-process mutex. The coordinator may grant ownership to another client after a deadline, yet the former holder can resume after a long pause and continue issuing operations based on authority it no longer has. The coordinator has done its job: it stopped treating the old client as the current holder. The shared resource has a different problem. Unless operations carry evidence of ownership order, the resource may have no basis for distinguishing a current holder from a stale one.

Software Engineering Distributed Systems

Software Engineering / 12 Sep 2026 / 7 min read

Compensation Is Not Rollback Across Service Boundaries

Compensation Is Not Rollback Across Service Boundaries A local database rollback can erase uncommitted writes before other transactions are allowed to depend on them. A compensating operation has a different shape. It runs after an earlier operation has committed, often after that result has become visible to other components. That distinction changes the consistency model. Compensation does not restore a distributed system to a state in which the original action never occurred. It adds another state transition whose domain meaning offsets some consequence of the first one.

Software Engineering Distributed Systems

Software Engineering / 11 Sep 2026 / 9 min read

Cache-Aside Consistency: Prevent Stale Overwrites

Cache-Aside Consistency: Prevent Stale Overwrites Cache-aside is attractive because the application controls a simple protocol. A read checks the cache first. On a miss, it reads the database and places the result in the cache. A write updates the database and then invalidates or refreshes the cache. Each step is easy to describe. Concurrency makes the combined behavior less obvious. A delayed cache fill can publish an older database value after a newer write has already completed. The database remains correct, yet later readers can receive stale data from the cache. This article develops the race precisely and presents practical designs that keep an old fill from replacing a newer state.

Software Engineering Caching