Hacker News Reader

Comment by hasty_pudding | Hacker News Reader

I always thought CAP was weird because you can have both consistency and availability if you sync faster than requests come in to the system.

View on HN

Like a spherical cow, there are some assumptions we need to make in a 101 class. For example, I remember my database professor saying that I need to assume my entire database does not fit in memory (RAM) because if it does, all bets are off.

The biggest fallacy of distributed systems: the network is always up.

You'd think that would be blindingly obvious, but based on every system in existence ... It's not.

Primarily I think it is marketing/sales since thinking properly about distributed systems is hard and executives don't want to hear about it.

That's what health checks are for yo! ;)

If you assume you can "sync faster than requests come in to the system", you've necessarily chosen C not-P, i.e. you don't have a distributed system (and in practice you've probably chosen not-A too).

CAP is a false choice. In practice, people choose (mostly C)+(mostly A)+(mostly P).

"Mostly consistent" is not good enough for many applications.

The thing most people pick in practice is CA, single master with hopefully a replicated backup.

Absolutely. And that's the right choice IF you can make it. Switching to CP or AP is something you should do because you're forced to.

That's something lost on a lot of modern engineers, I think. Distributed Systems are something you do because you have to, not because they're the best approach inherently.

That’s because for many use cases, you don’t need to be perfect.

The theorem is about being perfectly C, A, and P

You've misunderstood the theorem. It doesn't say you can't achieve any combination of mostly C/A/P; it says you can't have perfect C, A, and P at the same time.

Those things are binary. You have them or mot. Theres no: 'mostly'.

If you have more than two hosts, you have P.

If you have delay to sync, you have C.

If you send inaccurate data instead of waiting you have A.

Theres no 'mostly'

if you choose consistency than the only negative result of a distributed system is consistency based latency. i.e. Time to become consistent which reduces your response time to the client.

so there's a linear relationship between reducing sync time and reducing response time until at some point in reducing sync time you reduce response time below a level you give a shit about...

and you have all 3 of consistency, availability, and partitioning

and then you have beaten the CAP theory

In this case you are assuming not to have P. The traditional idea of "pick 2 of 3" with respect to CAP is weirdly formulated because you either have a distributed system, in which case P is a given and you must trade C vs A, or you don't have a distributed system and can therefore have both C and A.

I think there needs to be another variable which is response time.

Because you can have a well partitioned system with good data redundancy, and you can take time to let the system become consistent which reduces availability.

But the actual practical outcome of changing availability is changing response time.

Therefore, consistency time is directly and linearly related to response time.

And if the response time is below some threshold that you no longer care about then you have beaten CAP theorem.

So in a practical sense, you can beat the CAP theorem. In an abstract sense you cant.

But response time grounds the theorem to reality because it in every system, there's a point of optimization that no longer matters.

Reply on news.ycombinator.com