{
  "status": "unknown",
  "advantages": [],
  "limitations": [],
  "supersedes": [],
  "supersededBy": [],
  "firstSeen": null,
  "lastSeen": null,
  "updated": "2026-11-10",
  "slug": "invariant-confluence",
  "term": "Invariant confluence",
  "aliases": [
    "I-confluence"
  ],
  "definition": "Invariant confluence requires valid states reachable from a common ancestor to remain valid when merged under the specified transactions and merge rule.",
  "note": "Contract: Specify the initial state, permitted transactions, invariant and merge operator together. Checking each replica locally is insufficient if their merged result can violate the invariant. [invariant-confluence]\n\nGuarantee: In the paper's model, invariant confluence characterizes when invariant preservation, transactional availability, convergence and coordination-free execution can coexist. Changing the operations or merge rule changes the question. [invariant-confluence]",
  "related": [
    "calm-theorem",
    "cap-theorem",
    "serializability",
    "write-skew",
    "escrow-transactions",
    "bounded-counter"
  ],
  "citations": [
    {
      "id": "invariant-confluence",
      "title": "Bailis et al. Coordination Avoidance in Database Systems. PVLDB 8(3), 185-196 (2014), sections 3-5.",
      "url": "https://www.vldb.org/pvldb/vol8/p185-bailis.pdf",
      "accessed": "2026-11-10"
    }
  ],
  "provenance": [
    "Primary-source synthesis of the formal criterion, not a claim that arbitrary weakly consistent databases preserve application invariants."
  ]
}