gcgraceseconds, Riak's delete mode) bound tombstone lifetime relative to maximum expected node downtimeDate: 2026-05-29
Time: 13:38
Now I have a complete picture. Here's the explanation:
leaderless-replication/dynamo.py:antientropyrepair — Trace how the key-union + max-version logic would need to change to propagate tombstones instead of resurrecting deleted keyshinted-handoff/hintedhandoff.py — The TTL-based hint expiration at lines 7-18 is the closest existing pattern to gcgrace_seconds; compare the tradeoff between hint TTL and tombstone TTLvector-clocks/vectorclock.py:VersionedKVStore.receive_replica — Causality-aware replication with dominance checks; a tombstone version must dominate the live value for deletion to propagate, making this the most complex place to add tombstone supportmerkle-tree-anti-entropy — Real Cassandra/Dynamo use Merkle trees to efficiently detect replica divergence instead of full-keyspace scans; understanding this is prerequisite to implementing efficient tombstone propagation at scaletombstone-compaction-interaction — How gcgraceseconds interacts with SSTable compaction strategy (size-tiered vs. leveled) to determine when a tombstone is actually physically removed from diskdistributed-tombstone-gc-requires-downtime-bound — Any tombstone garbage collection strategy must define a maximum tolerated node downtime; tombstones removed before a down node receives them cause data resurrection via read repair or anti-entropydynamo-anti-entropy-unions-all-keys — antientropyrepair() discovers keys via set union across all available nodes (dynamo.py:183-185), so a key present on any single node propagates to all others — making naive deletes impossible without tombstonesgc-grace-seconds-is-repair-window — Cassandra's gcgraceseconds (default 10 days) defines the window during which anti-entropy must propagate a tombstone to all replicas; it is not a storage optimization but a correctness parameter tied to maximum expected node downtimereference-implementations-lack-tombstone-ttl — None of the DDIA reference implementations combine tombstone support with time-bounded garbage collection; the multi-leader module stores tombstones indefinitely and the Dynamo module has no delete support at alltombstone-lifetime-space-safety-tradeoff — Longer tombstone lifetimes waste storage but tolerate longer outages; shorter lifetimes save space but risk resurrection — Riak's three delete modes (keep/timeout/immediate) represent three explicit points on this spectrum