{
  "status": "unknown",
  "advantages": [],
  "limitations": [],
  "supersedes": [],
  "supersededBy": [],
  "firstSeen": null,
  "lastSeen": null,
  "updated": "2026-11-10",
  "slug": "causal-consistency",
  "term": "Causal consistency",
  "aliases": [],
  "definition": "Causal consistency requires reads to respect dependencies between operations while allowing concurrent writes to be ordered differently by different observers.",
  "note": "Program order, a read taking its value from a write, and transitivity establish potential causality. For read/write registers, each process must have a legal view of its own operations and all writes that preserves this order. A read returns the value of the latest preceding write to that key in that view, or the initial value if none exists. [causal-memory]\n\nConcurrent means unordered by causality, not simultaneous on a clock. Plain causal consistency does not require one shared order of concurrent writes. An overwritten intermediate value can remain unread. [causal-memory]\n\nCausal+ additionally requires convergent conflict handling. The 2011 COPS design checks dependencies before exposing replicated writes, and its COPS-GT extension adds consistent multi-key reads. The model assumes communication between threads passes through the store. [cops]\n\nThe COPS client tracks key/version pairs rather than fetching each value's full dependency list. After a put, its context retains only that put, which transitively represents its earlier dependencies. COPS-GT keeps additional dependency information for get transactions. [cops]\n\nAn ordering guarantee alone is not a durability promise. A documented causal-session configuration permits acknowledged writes to roll back. [causal-durability]",
  "related": [
    "session-guarantees",
    "eventual-consistency",
    "read-atomic-isolation"
  ],
  "citations": [
    {
      "id": "causal-memory",
      "title": "Ahamad et al. Causal memory: definitions, implementation, and programming. Distributed Computing 9, 37-49 (1995), sections 1, 2 and 4.",
      "url": "https://i2docker.moves.rwth-aachen.de/i2/fileadmin/user_upload/documents/Seminar_MCMM11/Causal_memory_1996.pdf",
      "accessed": "2026-11-10"
    },
    {
      "id": "cops",
      "title": "Lloyd et al. Don't Settle for Eventual: Scalable Causal Consistency for Wide-Area Storage with COPS. SOSP 2011, sections 3, 4.3, 4.4 and 4.6.",
      "url": "https://pages.cs.wisc.edu/~remzi/Classes/739/Papers/cops-sosp11.pdf",
      "accessed": "2026-11-10"
    },
    {
      "id": "causal-durability",
      "title": "MongoDB Manual: Causal Consistency and Read and Write Concerns; durability and rollback.",
      "url": "https://www.mongodb.com/docs/manual/core/causal-consistency-read-write-concerns/",
      "accessed": "2026-11-10"
    },
    {
      "id": "hesela-causal-visibility",
      "title": "Hesela: Replica repair and causal visibility",
      "url": "https://hesela.com/analyses/replica-repair-coverage/#causal-visibility",
      "accessed": "2026-11-10"
    }
  ],
  "provenance": [
    "Ahamad et al. (1995), sections 1, 2 and 4, and COPS (2011), sections 3-4.6 and Appendix A, establish the scoped definitions. The PDF filename containing 1996 does not change the printed publication year.",
    "The MongoDB documentation supplies a configuration-specific rollback example, not a claim that every causal implementation rolls back writes.",
    "No system execution or benchmark reproduction was performed. Status is unknown because this is a semantic guarantee, not a product lifecycle."
  ]
}