Talk:CAP theorem

Talk
Consistency here is not in the same sense as ACID consistency. ACID consistency is about transactions, this is about the differences of data between servers. Please fix.

I can disprove the theorem easily as it is worded in this article: a readonly distributed system. Note there was no requirement mentioned that the data in the distributed system changes. — Preceding unsigned comment added by Aarnott (talk • contribs) 03:17, 9 June 2011 (UTC)

Don't say "obviating the need for availability" -- just say "obviating availability."

To "obviate" means to "remove the need for." — Preceding unsigned comment added by 199.46.196.230 (talk) 20:43, 7 June 2012 (UTC)

As written, the distinction between Availability and Partition Tolerance isn't clear to me. Would it be better to replace the word "operate" with something like "return Consistent responses"? Ma-Ma-Max Headroom (talk) 17:02, 24 May 2019 (UTC)
 * You mean change "The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes" to "The system continues to return consistent responses despite an arbitrary number of messages being dropped (or delayed) by the network between nodes"? No, that would be inappropriate; that's specifically not what partition tolerance means. The system may well return inconsistent responses in such a case. --Yamla (talk) 17:11, 24 May 2019 (UTC)

Formulation
I don't understand how the article can at the same time declare a certain assert a theorem in the lead section and then proceed to explain that that's not the proven assert. The formulation used by Seth Gilbert and Nancy Lynch needs to be presented as a theorem, and then the history section can contain the conjecture; or the article needs to be about the conjecture and proceed to explain what's actually the theorem. --Nemo 17:28, 24 July 2014 (UTC)

Copy/paste
The "Brewer’s 2012 article" section is straight copy/paste from the 2012 IEEE article with no context. --207.38.161.127 (talk) 02:46, 16 April 2015 (UTC)

Is this part notable or not?
In 2002, Seth Gilbert and Nancy Lynch of MIT published a formal proof of Brewer's conjecture, rendering it a theorem. This last claim has been criticized, however, this reference does not offer a peer-reviewed formal proof – just an informal assertion on a blog posting.

Either the blog post is notable and thus stays in the article, or it is not notable and should be removed from the article. Introducing an argument just to dismiss it means this either this sentence violates NPOV or the reference violates Notability. 204.148.42.142 (talk) 21:52, 13 March 2017 (UTC)


 * You appear to have misunderstood Wikipedia's policies. See WP:NOTEWORTHY: "The criteria applied to the creation or retention of an article are not the same as those applied to the content inside it. The notability guidelines do not apply to contents of articles." --Guy Macon (talk) 10:44, 12 March 2018 (UTC)

Examples
Probably some examples could be added, not completely sure so waiting to somebody to confirm that is is ok to added to main article.
 * AP (Available and Partition Tolerant): Cassandra y CouchDB.
 * CP (Consistent and Partition Tolerant): MongoDB y Paxos.
 * CA (Consistent and Available): RDBMS. — Preceding unsigned comment added by Tech201805 (talk • contribs) 13:21, 18 May 2018 (UTC)


 * I think this would be a fine addition, but we need sources to go with the examples. See WP:V and WP:RS. --Guy Macon (talk) 15:11, 18 May 2018 (UTC)

Critique
I went through Mark Burgess's blog post "Deconstructing the `CAP theorem' for CM and DevOps" and there are some statements/critique worth mentioning in the article: -- mj41 (talk) 16:49, 18 October 2020 (UTC)
 * Brewer's original conjecture has not been proven with mathematical rigour -- indeed, the formulation in terms of C, A and P is too imprecise for that to happen. So the status of CAP as a theorem is something of an urban myth, but read on.
 * The definition of consistency in distributed systems does not usually include the end user, which itself seems inconsistent. Thus a database can be defined as consistent and users can still end up with different answers beyond the system boundary. Why don't we care about this?
 * and probably more


 * The problem is that "partition tolerance" = no partition on the side trying to achieve Consistency. Like Wiki says in the intro the "tolerance" is to tolerance to dropped packets which makes it consistent with C but not A. Redefine C+P = bytes of communication per round per node needed to prove consistency on the largest partition.  Define A as rounds/second. N = number of nodes. This gives
 * (C+P) * A * N < BW
 * where BW is the max bandwidth (bytes/sec) of the average node. So the tradeoff triangle, scalability trilemma, and a working version of CAP refer to the 3 aspects that compete for each node's limited BW. N = decentralization metric, A = scalability and C+P = overhead = level of security aka consistency among the largest group of voters.


 * Here's an excerpt from Gilbert and Lynch's "proof" of CAP's trilemma where they had to say "no partitions" instead of "no partition tolerance" in order for their "proof" to make sense.
 * Partitions .jpg


 * Ywaz (talk) 15:30, 22 November 2020 (UTC)