{"action":"created","issue":{"url":"https://api.github.com/repos/rethinkdb/docs/issues/766","labels_url":"https://api.github.com/repos/rethinkdb/docs/issues/766/labels{/name}","comments_url":"https://api.github.com/repos/rethinkdb/docs/issues/766/comments","events_url":"https://api.github.com/repos/rethinkdb/docs/issues/766/events","html_url":"https://github.com/rethinkdb/docs/issues/766","id":77838584,"number":766,"title":"Clarify CAP theorem limitations","user":{"login":"danielcompton","id":811954,"avatar_url":"https://avatars.githubusercontent.com/u/811954?v=3","gravatar_id":"","url":"https://api.github.com/users/danielcompton","html_url":"https://github.com/danielcompton","followers_url":"https://api.github.com/users/danielcompton/followers","following_url":"https://api.github.com/users/danielcompton/following{/other_user}","gists_url":"https://api.github.com/users/danielcompton/gists{/gist_id}","starred_url":"https://api.github.com/users/danielcompton/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danielcompton/subscriptions","organizations_url":"https://api.github.com/users/danielcompton/orgs","repos_url":"https://api.github.com/users/danielcompton/repos","events_url":"https://api.github.com/users/danielcompton/events{/privacy}","received_events_url":"https://api.github.com/users/danielcompton/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-05-18T22:57:37Z","updated_at":"2015-05-19T20:18:48Z","closed_at":null,"body":"Overall I think you've done a great job on the architecture docs and explaining the trade-offs you made. However there was one section that I thought could be a little clearer.\r\n\r\n> In RethinkDB data always remains immediately consistent and conflict-free, and a read that follows a write is always guaranteed to see the write.\r\n\r\nWhile this is technically true, it would probably be more accurate to say something like:\r\n\r\n> In RethinkDB data always remains immediately consistent and conflict-free, and a read that follows a write is always guaranteed to see the write (but neither the read nor write are guaranteed to succeed if the server is unavailable).\r\n\r\nYou talk about the failure scenarios further down, but as this is the first part of the CAP section, I think it would be helpful to give people a general understanding before continuing into the details. As it stands, without explicitly acknowledging the failure scenario (especially when discussing the CAP theorem), it seems like you're claiming that it is always immediately consistent and always available (which you're not, and the docs further down make that clear).\r\n\r\nWhat are your thoughts?"},"comment":{"url":"https://api.github.com/repos/rethinkdb/docs/issues/comments/103657243","html_url":"https://github.com/rethinkdb/docs/issues/766#issuecomment-103657243","issue_url":"https://api.github.com/repos/rethinkdb/docs/issues/766","id":103657243,"user":{"login":"danielmewes","id":505365,"avatar_url":"https://avatars.githubusercontent.com/u/505365?v=3","gravatar_id":"","url":"https://api.github.com/users/danielmewes","html_url":"https://github.com/danielmewes","followers_url":"https://api.github.com/users/danielmewes/followers","following_url":"https://api.github.com/users/danielmewes/following{/other_user}","gists_url":"https://api.github.com/users/danielmewes/gists{/gist_id}","starred_url":"https://api.github.com/users/danielmewes/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/danielmewes/subscriptions","organizations_url":"https://api.github.com/users/danielmewes/orgs","repos_url":"https://api.github.com/users/danielmewes/repos","events_url":"https://api.github.com/users/danielmewes/events{/privacy}","received_events_url":"https://api.github.com/users/danielmewes/received_events","type":"User","site_admin":false},"created_at":"2015-05-19T20:18:48Z","updated_at":"2015-05-19T20:18:48Z","body":"That's a great improvement @danielcompton, I agree that your version is much clearer.\r\n\r\nWe might want to wait for our next release (which will come with auto failover) before updating this, since then we can make it even more accurate:\r\n> In RethinkDB data always remains immediately consistent and conflict-free, and a read that follows a write is always guaranteed to see the write (but neither reads nor writes are guaranteed to succeed *if a majority of servers* is unavailable)."}}