Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update README.md #34

Merged
merged 1 commit into from
Aug 6, 2024
Merged

Update README.md #34

merged 1 commit into from
Aug 6, 2024

Conversation

umutphp
Copy link
Owner

@umutphp umutphp commented Aug 6, 2024

Fix typo

@umutphp umutphp merged commit fe22937 into master Aug 6, 2024
11 checks passed
Copy link

github-actions bot commented Aug 6, 2024

Hi @umutphp,

A random law from Hacker Laws repository is a small gift to thank you for opening the PR.


CAP Theorem (Brewer's Theorem)

The CAP Theorem (defined by Eric Brewer) states that for a distributed data store only two out of the following three guarantees (at most) can be made:

  • Consistency: when reading data, every request receives the most recent data or an error is returned
  • Availability: when reading data, every request receives a non error response, without the guarantee that it is the most recent data
  • Partition Tolerance: when an arbitrary number of network requests between nodes fail, the system continues to operate as expected

The core of the reasoning is as follows. It is impossible to guarantee that a network partition will not occur (see The Fallacies of Distributed Computing). Therefore in the case of a partition we can either cancel the operation (increasing consistency and decreasing availability) or proceed (increasing availability but decreasing consistency).

The name comes from the first letters of the guarantees (Consistency, Availability, Partition Tolerance). Note that it is very important to be aware that this does not relate to ACID, which has a different definition of consistency. More recently, PACELC theorem has been developed which adds constraints for latency and consistency when the network is not partitioned (i.e. when the system is operating as expected).

Most modern database platforms acknowledge this theorem implicitly by offering the user of the database the option to choose between whether they want a highly available operation (which might include a 'dirty read') or a highly consistent operation (for example a 'quorum acknowledged write').

Real world examples:

  • Inside Google Cloud Spanner and the CAP Theorem - Goes into the details of how Cloud Spanner works, which appears at first to seem like a platform which has all of the guarantees of CAP, but under the hood is essentially a CP system.

See also:

  • ACID
  • The Fallacies of Distributed Computing
  • PACELC

     github.com/dwmkerr/hacker-laws by Dave Kerr 

@umutphp umutphp deleted the umutphp-patch-1 branch September 12, 2024 22:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant