116 lines
5.0 KiB
HTML
116 lines
5.0 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html;charset=UTF-8">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<link rel="shortcut icon" href="https://ferd.ca/static/img/favicon.ico" type="image/x-icon"/>
|
|
<title>Beating the CAP Theorem Checklist</title>
|
|
<link rel="stylesheet" href="https://ferd.ca/static/css/style.css?20250117" />
|
|
<link href="https://ferd.ca/feed.rss" type="application/rss+xml" rel="alternate" title="ferd.ca newsfeed" />
|
|
|
|
|
|
</head>
|
|
|
|
<body>
|
|
<div class="container">
|
|
<header class="row">
|
|
<h1 class="nine columns"><a href="https://ferd.ca/" title="home"><span class="hilight">“</span>My bad opinions<span class="hilight">”</span></a></h1>
|
|
<menu class="three columns">
|
|
<li><a class="" href="https://ferd.ca/" title="deliberate writings and talk transcripts">blog</a></li>
|
|
<li><a class="" href="https://ferd.ca/notes/" title="random writings, notes, quotes and paper summaries">notes</a></li>
|
|
<li><a class="" href="https://ferd.ca/about.html" title="whose the hell is writing stuff">about</a></li>
|
|
</menu>
|
|
</header>
|
|
|
|
<article class="row">
|
|
<div>
|
|
|
|
<h2>Beating the CAP Theorem Checklist</h2>
|
|
<div id="content">
|
|
|
|
|
|
<pre>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:
|
|
|
|
( ) you are assuming that software/network/hardware failures will not happen
|
|
( ) you pushed the actual problem to another layer of the system
|
|
( ) your solution is equivalent to an existing one that doesn't beat CAP
|
|
( ) you're actually building an AP system
|
|
( ) you're actually building a CP system
|
|
( ) you are not, in fact, designing a distributed system
|
|
|
|
Specifically, your plan fails to account for:
|
|
|
|
( ) latency is a thing that exists
|
|
( ) high latency is indistinguishable from splits or unavailability
|
|
( ) network topology changes over time
|
|
( ) there might be more than 1 partition at the same time
|
|
( ) split nodes can vanish forever
|
|
( ) a split node cannot be differentiated from a crashed one by its peers
|
|
( ) clients are also part of the distributed system
|
|
( ) stable storage may become corrupt
|
|
( ) network failures will actually happen
|
|
( ) hardware failures will actually happen
|
|
( ) operator errors will actually happen
|
|
( ) deleted items will come back after synchronization with other nodes
|
|
( ) clocks drift across multiple parts of the system, forward and backwards in time
|
|
( ) things can happen at the same time on different machines
|
|
( ) side effects cannot be rolled back the way transactions can
|
|
( ) failures can occur while in a critical part of your algorithm
|
|
( ) designing distributed systems is actually hard
|
|
( ) implementing them is harder still
|
|
|
|
And the following technical objections may apply:
|
|
|
|
( ) your solution requires a central authority that cannot be unavailable
|
|
( ) read-only mode is still unavailability for writes
|
|
( ) your quorum size cannot be changed over time
|
|
( ) your cluster size cannot be changed over time
|
|
( ) using 'infinite timeouts' is not an acceptable solution to lost messages
|
|
( ) your system accumulates data forever and assumes infinite storage
|
|
( ) re-synchronizing data will require more bandwidth than everything else put together
|
|
( ) acknowledging reception is not the same as confirming consumption of messages
|
|
( ) you don't even wait for messages to be written to disk
|
|
( ) you assume short periods of unavailability are insignificant
|
|
( ) you are basing yourself on a paper or theory that has not yet been proven
|
|
|
|
Furthermore, this is what I think about you:
|
|
|
|
( ) nice try, but blatantly false advertising
|
|
( ) you are badly reinventing existing concepts and should do some research
|
|
( ) in particular, you should read the definition of the word 'theorem'
|
|
( ) also you should read the definition of 'distributed system'
|
|
( ) you have no idea what you are doing
|
|
( ) do you even know what a logical clock is?
|
|
( ) you shouldn't be in charge of people's data
|
|
</pre>
|
|
|
|
<p>Also thanks to <a href="http://programmingisterrible.com/">tef</a> for some editing.</p>
|
|
|
|
|
|
</div>
|
|
</div>
|
|
</article>
|
|
|
|
<footer class="row">
|
|
<div class="contact six columns">
|
|
<ul>
|
|
<li><a href="mailto:mononcqc+ferdca@ferd.ca">Fred Hebert</a></li>
|
|
<li><a rel="me" href="https://hachyderm.io/@mononcqc">Mastodon</a>, <a rel="me" href="https://bsky.app/profile/ferd.ca">bsky</a></li>
|
|
<li><a href="https://ferd.ca/feed.rss" type="application/rss+xml" rel="alternate">RSS</a></li>
|
|
</ul>
|
|
</div>
|
|
<div class="publications six columns">
|
|
<ul>
|
|
<li><a href="https://pragprog.com/titles/fhproper/property-based-testing-with-proper-erlang-and-elixir/">Property-Based Testing with PropEr</a></li>
|
|
<li><a href="https://www.erlang-in-anger.com/">Erlang in Anger</a></li>
|
|
<li><a href="https://learnyousomeerlang.com">Learn You Some Erlang</a></li>
|
|
</ul>
|
|
</div>
|
|
</footer>
|
|
</div>
|
|
</body>
|
|
</html>
|
|
|