forked from ahangchen/dirtysalt.github.io
-
Notifications
You must be signed in to change notification settings - Fork 0
/
beating-the-cap-theorem-checklist.html
90 lines (83 loc) · 4.96 KB
/
beating-the-cap-theorem-checklist.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Beating the CAP Theorem Checklist</title>
<meta name="generator" content="Org-mode" />
<meta name="author" content="dirtysalt" />
<link rel="shortcut icon" href="http://dirtysalt.info/css/favicon.ico" />
<link rel="stylesheet" type="text/css" href="./css/site.css" />
</head>
<body>
<div id="content">
<h1 class="title">Beating the CAP Theorem Checklist</h1>
<p>
Your ( ) tweet ( ) blog post ( ) marketing material ( ) online comment
advocates a way to beat the CAP theorem. Your idea will not work. Here is why
it won't work:
</p>
<ul class="org-ul">
<li>( ) you are assuming that software/network/hardware failures will not happen</li>
<li>( ) you pushed the actual problem to another layer of the system</li>
<li>( ) your solution is equivalent to an existing one that doesn't beat CAP</li>
<li>( ) you're actually building an AP system</li>
<li>( ) you're actually building a CP system</li>
<li>( ) you are not, in fact, designing a distributed system</li>
</ul>
<p>
Specifically, your plan fails to account for:
</p>
<ul class="org-ul">
<li>( ) latency is a thing that exists</li>
<li>( ) high latency is indistinguishable from splits or unavailability</li>
<li>( ) network topology changes over time</li>
<li>( ) there might be more than 1 partition at the same time</li>
<li>( ) split nodes can vanish forever</li>
<li>( ) a split node cannot be differentiated from a crashed one by its peers</li>
<li>( ) clients are also part of the distributed system</li>
<li>( ) stable storage may become corrupt</li>
<li>( ) network failures will actually happen</li>
<li>( ) hardware failures will actually happen</li>
<li>( ) operator errors will actually happen</li>
<li>( ) deleted items will come back after synchronization with other nodes</li>
<li>( ) clocks drift across multiple parts of the system, forward and backwards in time</li>
<li>( ) things can happen at the same time on different machines</li>
<li>( ) side effects cannot be rolled back the way transactions can</li>
<li>( ) failures can occur while in a critical part of your algorithm</li>
<li>( ) designing distributed systems is actually hard</li>
<li>( ) implementing them is harder still</li>
</ul>
<p>
And the following technical objections may apply:
</p>
<ul class="org-ul">
<li>( ) your solution requires a central authority that cannot be unavailable</li>
<li>( ) read-only mode is still unavailability for writes</li>
<li>( ) your quorum size cannot be changed over time</li>
<li>( ) your cluster size cannot be changed over time</li>
<li>( ) using 'infinite timeouts' is not an acceptable solution to lost messages</li>
<li>( ) your system accumulates data forever and assumes infinite storage</li>
<li>( ) re-synchronizing data will require more bandwidth than everything else put together</li>
<li>( ) acknowledging reception is not the same as confirming consumption of messages</li>
<li>( ) you don't even wait for messages to be written to disk</li>
<li>( ) you assume short periods of unavailability are insignificant</li>
<li>( ) you are basing yourself on a paper or theory that has not yet been proven</li>
</ul>
<p>
Furthermore, this is what I think about you:
</p>
<ul class="org-ul">
<li>( ) nice try, but blatantly false advertising</li>
<li>( ) you are badly reinventing existing concepts and should do some research</li>
<li>( ) in particular, you should read the definition of the word 'theorem'</li>
<li>( ) also you should read the definition of 'distributed system'</li>
<li>( ) you have no idea what you are doing</li>
<li>( ) do you even know what a logical clock is?</li>
<li>( ) you shouldn't be in charge of people's data</li>
</ul>
</div>
<!-- DISQUS BEGIN --><div id="disqus_thread"></div><script type="text/javascript">/* * * CONFIGURATION VARIABLES: EDIT BEFORE PASTING INTO YOUR WEBPAGE * * *//* required: replace example with your forum shortname */var disqus_shortname = 'dirlt';var disqus_identifier = 'beating-the-cap-theorem-checklist.html';var disqus_title = 'beating-the-cap-theorem-checklist.html';var disqus_url = 'http://dirtysalt.github.io/beating-the-cap-theorem-checklist.html';/* * * DON'T EDIT BELOW THIS LINE * * */(function() {var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;dsq.src = '//' + disqus_shortname + '.disqus.com/embed.js';(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);})();</script><noscript>Please enable JavaScript to view the <a href="http://disqus.com/?ref_noscript">comments powered by Disqus.</a></noscript><a href="http://disqus.com" class="dsq-brlink">comments powered by <span class="logo-disqus">Disqus</span></a><!-- DISQUS END --></body>
</html>