
You Can’t Sacrifice Partition Tolerance (2010) - xrorre
https://codahale.com/you-cant-sacrifice-partition-tolerance/
======
kerkeslager
Maybe I'm missing something, but it seems like this is basically just glossing
over this part:

> Some systems cannot be partitioned. Single-node systems (e.g., a monolithic
> Oracle server with no replication) are incapable of experiencing a network
> partition. But practically speaking these are rare;

I'm not sure how the writer came to the conclusion that these systems are
rare. The website I'm working on now has a single monolithic Postgres server,
and the majority of systems I've worked on connected to single monolithic
datastores, so at the very least these systems exist. These aren't
particularly _interesting_ examples, but when talking theoretically like with
the CAP theorem, you don't get to just ignore the rare or uninteresting cases.
These seem like relatively common examples of choosing CA.

Of course, when you try to shard such databases, you're going to run into
serious problems.

I guess the claim I can credit to the author is that CA _really really really_
means _no partition tolerance_. _Even one network partition_ puts you in CP or
AP territory. But I don't think that means CA stores don't exist.

It may be that I'm just not understanding things correctly, though; the CAP
paper is definitely a challenging read for me.

~~~
chillacy
If you read the next sentence he says

> But practically speaking these are rare; add remote clients to the
> monolithic Oracle server and you get a distributed system which can
> experience a network partition (e.g., the Oracle server becomes
> unavailable).

~~~
statictype
The theory in question addresses distributed database systems. A remote client
connected to a monolithic database is not a distributed database system. If
there is a network partition between the client and the server then you don't
get C or A. You get nothing.

The P refers to partitions between nodes of the database system. Not clients.

So that point in the article doesn't seem to make sense.

~~~
zzzcpan
> You get nothing.

You don't get nothing, you get inconsistency that could require even human
intervention to fix. For example, if client lost connection right before the
database was able to respond that his commit was successful. Client then
retries and you get a typical double billing problem.

That's because monolithic database with a remote client is in fact a
distributed system and strong consistency in a distributed system requires
proper distributed algorithms and protocols, where clients are nodes too. You
cannot guaranty consistency otherwise (to be precise, you will need clients to
be able to wait indefinitely to guaranty strong total consistency, but if
clients are used by humans they will not do that and the only consistency you
can guaranty for a human is eventual consistency).

------
aminorex
The implication derived from a trivial probability argument is misleading.
Failures are correlated, so 1-(1-P)^n is an upper bound, firstly, but secondly
and much more importantly, the value being computed is the wrong value.
Failure of a node is not partition. To non-trivially partition a cluster of N
nodes requires (N-2) failures, when the cluster is fully connected, for
example (as e.g. on any bus network). Handling trival partition is, well,
trivial, in some important senses.

------
sciurus
It's worth keeping in mind that viewing a system as CP or AP usually isn't
nuanced enough: [https://martin.kleppmann.com/2015/05/11/please-stop-
calling-...](https://martin.kleppmann.com/2015/05/11/please-stop-calling-
databases-cp-or-ap.html)

------
zaroth
Liked everything up to this part;

"When it comes to designing or evaluating distributed systems, then, I think
we should focus less on which two of the three Virtues we like most and more
on what compromises a system makes as things go bad."

It seemed like the entire point was that really there are only 2 Virtues
(Consistency, Availability) and given a partition you will chose one or the
other. The only database that doesn't have network partitions also isn't
distributed.

~~~
zzzcpan
> and given a partition you will chose one or the other

There is no sacrificing consistency though. It's about whether you use CRDTs
or something to keep the system working when network partition happens or you
don't and let the system stop working.

------
throwaway_exer
The original CAP paper was intended as a high-level discussion item for
students. Brewer has since emphasized that it is more of an academic approach
than applicable to real-world distributed databases.

Other computer scientists have either modified or narrowed it to be more
useful.

So it's fun to read the original CAP paper, but it's less useful than you
would expect. When somebody asks me about CP vs. CA, I realize they in fact
don't anything at all about distributed databases.

