What is Data Consistency?
Consistency is a measure of how up to date a piece of data in a distributed system is.
A read that reflects all of the updates on a piece of data comes from a highly consistent system. A read that returns stale data, old data without the recent updates, comes from an inconsistent or weakly consistent system.
Consistency matters for two reasons:
- A highly consistent system is easier to reason about, because every update is reflected in all of the data in the system.
- Users appreciate their changes being reflected. A user likes a post and refreshes the page. The like is still on the post, and the user is happy. A like that has not been registered after the refresh is not appealing.
It is the engineer's responsibility to make a system as consistent as possible. The chapter covers the different levels of consistency a system can provide to its users, who are end users of the application or other engineers hitting the service APIs.
Linearizable Consistency
Linearizable consistency is the highest level of consistency: every update is reflected in every read request.
The system is a single room with a single door, and each person is a request. A request enters the room, is processed and leaves. All other requests wait in a queue. With ordering forced in the queue, every request is processed in sequence, as if there is only one computer.
The guarantee has two costs:
- High latency. A request that takes a long time inside the room makes everybody wait. This is head of line blocking.
- Low availability. A request that cannot be processed stops the system from responding, so the room is a single point of failure.
Users get a highly consistent view of the world, and they rarely see it.
A single thread implements this in a server, because all instructions inside it are executed in order. The thread is the queue and the processor is the room. Protocols like Raft maintain the ordering across distributed systems.
Eventual Consistency
Eventual consistency is the polar opposite of linearizable consistency: the server does not look at the ordering of the requests.
A write request sets key 1 to 31, and a read request for key 1 follows it. The server sends both requests on in parallel. Three things make that possible:
- Different servers get different requests.
- The requests run concurrently on different threads.
- The database runs the queries in parallel.
The responses can then come out of order. The read is executed first and the write second, so the read returns 21.
A customer who changes the age on a profile from 21 to 31 and reads the page still sees 21. The customer retries the request and gets worried. A stale read like this is a problem for some applications.
For others it is fine. An email goes to the outbox, and after some time, when the request succeeds, it goes to the sent box. A refresh that still shows the email in the outbox is not scary, because eventually it is going to be sent.