Skip to content

[RESEARCH]: Foundational CRDT literature and OR-Set tombstone GC for the full Redis type surface #163

@ELares

Description

@ELares

Filed from the IronCache pre-implementation coverage audit (2026-06-13): no existing issue adequately owned this.

Why this is needed

Ground the active-active design (#79) in primary CRDT literature rather than only the Redis Enterprise CRDB and KeyDB product behaviors: the state-based vs op-based vs delta-state tradeoff (Almeida/Shapiro), dotted version vectors for causally-correct OR-Set tombstone GC, and how the Redis types CRDB does NOT specify (sorted sets, hashes, lists) map to conflict-free types. This shapes the per-key metadata budget and member cap #79 leaves open, and whether a delta merge path keeps active-active memory inside the minimal-memory tenet. #79 grounds every borrow/adapt/reject on exactly two product implementations and explicitly leaves OR-Set GC and bytes-per-key-at-N-members open; grep of claims.yaml for delta-crdt/version-vector/dotted/Shapiro returns ZERO. The unresearched-literature layer UNDER #79, not a duplicate of it. (Streams excluded here per the Streams non-goal.)

Context

Relates to / partially overlaps #79. Part of the vision EPIC #1.

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:datastructuresArea: datastructuresarea:memoryArea: memoryarea:replicationArea: replicationresearchComparative research grounded in prior-art systemswave:3Readiness wave 3: clustering, AI advisor, tiering, advanced

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions