Replication

Software Engineering / 22 Sep 2026 / 6 min read

Tombstones Prevent Deleted Data from Reappearing

Tombstones Prevent Deleted Data from Reappearing Deletion is not merely the absence of a value in a replicated store. Absence carries no information about whether a key was deliberately removed or whether a replica has simply never received it. When replicas can be temporarily disconnected, that distinction determines whether synchronization preserves a deletion or accidentally restores old data. A tombstone records the deletion as versioned state. Replicas can compare that marker with older values and keep the deletion when they reconcile. The marker can eventually be reclaimed, but only after the system has a defensible boundary beyond which an older value cannot return.

Software Engineering Distributed Systems

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 / 21 Sep 2026 / 4 min read

Version Vectors Distinguish Concurrent Updates from Causal Successors

Version Vectors Distinguish Concurrent Updates from Causal Successors Replicated data can receive writes at different nodes while communication between those nodes is delayed. When versions later meet, a scalar revision number can say that two values differ, but it cannot always say whether one descends from the other or both were produced independently. A version vector records progress per replica. Comparing those counters provides a partial order: one version can dominate another, the vectors can be equal, or neither can dominate. The last case identifies concurrent histories that require an explicit reconciliation rule.

Software Engineering Distributed Systems

Software Engineering / 20 Sep 2026 / 7 min read

Tombstones Preserve Deletes Across Replicas Until Safe Garbage Collection

Tombstones Preserve Deletes Across Replicas Until Safe Garbage Collection Deleting a value from one copy of replicated data is not enough to delete it from the system. Another replica may be offline, delayed, or partitioned when the delete occurs. If the active replica simply removes the record, it also removes the evidence that a deletion happened. A stale replica can later return with an older value and make that value visible again.

Software Engineering Distributed Systems

Software Engineering / 15 Sep 2026 / 6 min read

Tombstones Preserve Deletions Across Replica Gaps

A replicated store cannot always represent deletion as immediate absence. If one replica removes a record while another replica is disconnected, erasing every trace of the record also erases the evidence needed to distinguish a deliberate deletion from a replica that simply has not seen recent state. A tombstone keeps that evidence as versioned metadata. Instead of removing the key from the replication domain at once, the system records a deletion marker that participates in reconciliation. A replica carrying an older live value can then compare its state with the marker and discard the obsolete value.

Software Engineering Distributed Systems