Data consistency
When data is copied across machines, who sees what, and when? Strong consistency, eventual consistency, the CAP theorem, quorums and reading your own writes, as definitions and scenarios, every answer explained.
- 32 cards
- 3 topics
- Free
The outline, topic by topic
Each topic is weighted the way the exam weighs it.
- Consistency models
- The CAP theorem
- Replicas and quorums
A few cards from the deck
What is “strong consistency”?
Show the answer
Every read sees the latest committed write, as if there were a single copy of the data
It is the easiest to reason about for developers, but each write must be coordinated across copies, which costs latency and availability.
For which data is eventual consistency perfectly fine?
- The number of likes under a post
- A bank account balance before a withdrawal
- The remaining stock of a concert's last ticket
- The lock that stops two people booking the same seat
Show the answer
The number of likes under a post
Showing 1,203 instead of 1,205 for a second bothers nobody. A balance, a last ticket or a booking, on the contrary, need the very latest value.
Every read sees the latest committed write, as if there were a single copy of the data: what is this called?
Show the answer
strong consistency
It is the easiest to reason about for developers, but each write must be coordinated across copies, which costs latency and availability.
A user changes their username, reloads the page and sees the old one. Reads go to a lagging replica. Which guarantee is missing?
- Read your own writes
- Availability
- Partition tolerance
- Encryption
Show the answer
Read your own writes
It can be guaranteed without making everything strongly consistent: send a user's reads to the primary right after their writes, or wait for the replica to catch up.