Data consistency refers to the idea that a highly concurrent distributed system should read and write data like a single node, centralised system. In these systems, data is replicated, cached, and accessed concurrently. Our goal is for our system to replicate a single-threaded system, where writing a value then reading the value is deterministic.
The main challenges:
- How do we order updates across replicas?
- How do we ensure updates occur exactly once?
- How do we ensure the latest data (non-stale data) is read?
- How do we ensure correctness under concurrent accesses?
- How do we ensure correctness under failures?
System models
A data consistency model describes the expected behaviour from a storage system when clients access data. Much like any distributed system model, it helps us reason key elements of the system (failures, implementation). Consistency models make a trade-off in application complexity, performance, and availability.
In general, weaker consistency models allow us to achieve higher performance and availability. And vice versa. For systems with a large amount of data or large frequency of updates, we shouldn’t be using linearisable systems.
Models include:
- Linearisability, a form of strong consistency where all clients see the same order of writes and read the latest data. This has the lowest performance and highest latency (since every request requires communication with a majority/quorum of replicas). It also has low availability, when nodes are down.
- Consider Raft. The followers basically only function to pull data from the leader. It’s not actually used to respond to client interactions.
- But this is ideal if we prioritise fault tolerance.
- Sequential consistency weakens linearisability by not providing real-time guarantees.
- Causal consistency
- FIFO consistency
- Eventual consistency is the weakest form of consistency. It allows for executions to occur in any order. As the name suggests, eventually replicas will converge to the same state eventually.
