system-design-primer/resources/noat.cards/04 Consistency patterns.md

33 lines
1.4 KiB
Markdown
Raw Normal View History

2021-03-14 18:13:28 +03:00
+++
noatcards = True
isdraft = False
2021-03-27 13:16:09 +03:00
weight = 40
2021-03-14 18:13:28 +03:00
+++
# Consistency patterns
## Introduction
2021-03-21 13:12:09 +03:00
With multiple copies of the same data, we are faced with options on how to synchronize them so clients have a consistent view of the data. Recall the definition of consistency from the [CAP theorem](https://github.com/donnemartin/system-design-primer#cap-theorem) - Every read receives the most recent write or an error.
2021-03-14 18:13:28 +03:00
2021-03-21 13:55:58 +03:00
## Weak consistency
2021-03-14 18:13:28 +03:00
After a write, reads may or may not see it. A best effort approach is taken.
This approach is seen in systems such as memcached. Weak consistency works well in real time use cases such as VoIP, video chat, and realtime multiplayer games. For example, if you are on a phone call and lose reception for a few seconds, when you regain connection you do not hear what was spoken during connection loss.
2021-03-21 13:55:58 +03:00
## Eventual consistency
2021-03-14 18:13:28 +03:00
After a write, reads will eventually see it (typically within milliseconds) . Data is replicated asynchronously.
This approach is seen in systems such as DNS and email. Eventual consistency works well in highly available systems.
2021-03-21 13:55:58 +03:00
## Strong consistency
2021-03-14 18:13:28 +03:00
After a write, reads will see it. Data is replicated synchronously.
This approach is seen in file systems and RDBMSes. Strong consistency works well in systems that need transactions.
2021-03-21 13:55:58 +03:00
## Source(s) and further reading
2021-03-14 18:13:28 +03:00
- [Transactions across data centers](http://snarfed.org/transactions_across_datacenters_io.html)