Skip to content

Instantly share code, notes, and snippets.

@rponte
Created December 2, 2010 16:03
Show Gist options
  • Save rponte/725566 to your computer and use it in GitHub Desktop.
Save rponte/725566 to your computer and use it in GitHub Desktop.
CAP - Consistency, Availability and Partition-Tolerant
CAP - Consistency, Availability and Partition-Tolerant
The CAP principle states that in distributed computing when it comes
to consistency (C), availability (A) and partition (P)
resilience/tolerance you can have only two of the three.
I was recently introduced to this principle and find it rather
insightful. Basically you can't have your cake and eat it too,
otherwise (computing) life would be too easy.
Eric Brewer, a University of California, Berkeley professor and the
co-founder and Chief Scientist of Inktomi, in a 2000 Principles of
Distributed Computing (PODC) talk, stated it was impossible for
distributed web services to guarantee consistency, availability and
partition-tolerance.
Consistency. Think database consistency. A read after an update
should reflect the update.
Availability. Highly available web services mean every requests
should succeed and receive a response.
Partition-tolerance. This arise out of the desire for
fault-tolerance. The service should be able to function when part of
network fails, when a partition between data replicas will still allow
the service to operate.
Take, for example, the Amazon S3 service (Simple Storage Service).
Users can upload data to Amazon, much like a simple FTP service, with
very high availability and scalability.
Amazon's S3 guarantees availability and partition-tolerance but does
not guarantee consistency. Data is replicated to many data centers,
and requests will continue to succeed even if communication between
data centers fail. However, it is possible that after an upload a
download on a different node would fail, because the data has not been
replicated to that node. The service is not consistent. Amazon
describes this as eventually consistent model.
On the other hand, take a service with distributed transactions. It
will be consistent and available, but if the network partitions the
service will not function.
Reference: Brewer's Conjecture and the Feasibility of Consistent,
Available, Partition-Tolerant Web Services, Seth Gilbert and Nancy
Lynch.
More infos, http://en.wikipedia.org/wiki/CAP_theorem
@ShanikaEdiriweera
Copy link

I think your example of Not being partition tolerant is a bit incorrect.

A distributed system is always partition tolerant and Consistency or Availability is compromised to some extent according to the need.

In the case of a service with distributed transactions, Consistency is more important and in case of network partition (and when updates are happening), the Availability is compromised.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment