Consistency Models

this article explains how data propagates among offline peers, data conflicts resulting from multiple offline edits to the same data known as concurrency conflicts and how ditto resolves them using specialized data types register , map , and attachment to summarize, ditto's causal consistency feature ensures consistency across related changes by allowing concurrent messages to appear in any order while maintaining consistency concurrency conflicts in ditto's decentralized architecture, data propagates asynchronously among offline peers, eliminating the need for a centralized authority like a central server to validate and merge database operations this decentralized model, however, presents the possibility of concurrency conflicts a concurrency conflict happens when multiple end users make changes to the same data items at the same time when merging these changes, any inconsistencies collide resolving data conflicts at merge to resolve concurrency collisions at merge, ditto turns to conflict free replicated data type ( crdt ) technology crdt is an advanced class of data type designed to manage and replicate data changes in a way that allows multiple distributed peers to make updates concurrently without needing to reach a consensus to form a single meaningful value for merge for an overview of the different crdts that ditto offers, see docid\ ayomyvdlpqeaav6tlgknk , docid 5x5bqsft43c8y0pfqcesl , and docid\ a6a5zsvtwsjg4qjg87hiy eventual consistency the following scenario provides a walkthrough of the mechanics of version vectors, their role in determining merging behavior, and how different peers contribute to data replication the hlc uses the uint128 data type to represent the site id and 64bit timestamp in ditto; however, for simplicity, the following scenario uses basic string and number types instead local peer a document 123abc links to a version vector that indicates its locally stored document is currently at vector version 5 the most recent incoming remote peer b changes were incorporated and merged at version 1 the remote peer c changes were incorporated and merged at vector version 4 documentid "123abc" version vector { "a" 5, "b" 1, "c" 4 } local peer a receives document changes from remote peer b the incoming document's version vector indicates the remote peer b incoming version vector is value 4 the most recent incoming remote peer b changes were of version 1 ; a value less than the incoming document version vector value of 4 since 4 is greater than 1 , the local peer a determines that the changes are new and should be incorporated and merged in order to remain consistent documentid "123abc" version vector { "a" 5, "b" 1, //merge in {"b" 4} because 4 > 1 "c" 4 } causal consistency guaranteed by ditto, causal consistency ensures that changes are causally consistent across multiple documents and different collections within the same ditto appid to give an intuition about causal consistency, imagine the following scenario on a social network, bob posts a message bob "i lost my cat" then after some time, he posts bob "i found him! what a relief!" to which sue replies sue "great news!" in contrast, an eventually consistent database shows messages in any order bob "i lost my cat" sue "great news!" bob etc ditto's causal consistency ensures that if a new message is written after seeing some prior message, then the new message is not visible unless that prior message is also visible to help differentiate causal consistency from stronger consistency models, imagine that alice replies alice "wonderful!" causal consistency allows the two concurrent messages "great news!" from sue and "wonderful!" from alice to appear in any order both of the following results are valid with causal consistency bob "i lost my cat" bob "i found him! what a relief!" sue "great news!" alice "wonderful!" and bob "i lost my cat" bob "i found him! what a relief!" alice "wonderful!" sue "great news!"