4 ms·

No, you can have availability and consistency as long as you have enough replicas. Network partitions that leave you w/o a quorum are like the whole cloud bein

No, you can have availability and consistency as long as you have enough replicas. Network partitions that leave you w/o a quorum are like the whole cloud being down. Network partitions don't leave some clients only able to reach non-quorums -- this is the big point of TFA.

kstrauser 2y ago
That presumes you can only have 1 partition at a time. That is not the case. You can optimize for good behavior when you end up with 2 disconnected graphs. It’s absolutely the case that a graph with N nodes can end up with N separate groups. Conceptually, imagine a single switch that connects all of them together and that switch dies. You can engineer cloud services to be resilient. AWS has done a great job of that in my personal experience. But worst cases can still happen. If you have an algorithm that runs in n*log(n) most of the time but 2^n sometimes, it can still be super useful. You have to prepare for the bad case though. If you say it’s been running great so far and we don’t worry about it, fine, but that doesn’t mean it can’t still blow up when it’s most inconvenient. It only means it hasn’t yet.
- cryptonector 2y ago
  Again, a partition that leaves you with no quorum anywhere is like the cloud being down.
  - pessimizer 2y ago
    A partition that leaves you with no quorum anywhere is like the cloud being down if you value consistency over availability.
    - cryptonector 2y ago
      Yes, but again, TFA says that you will trust the cloud will be up long enough that you would indeed prefer consistency. My goodness. So many commenters here today are completely ignoring TFA and giving lessons on CAP -- lessons that are correct, but which completely ignore that TFA is really arguing that clouds move the needle hard in one direction when considering the CAP trade-offs, to the point that "the CAP theorem is irrelevant for cloud systems" (which was this post's original title, though not TFA's).
      - pyrale 2y ago
        The issue people are pointing is that the author conflates "Cloud is good enough for my needs" with "CAP is no longer relevant".The point is especially annoying considering that the author works at a cloud vendor and not a cloud user.
  - robertlagrant 2y ago
    > Again, a partition that leaves you with no quorum anywhere is like the cloud being down. What does this mean? What is the cloud being down? The cloud isn't a single thing; it's lots of computers in lots of data centres.
    - NavinF 2y ago
      It means there will be an article on the front page declaring the outage
  - Spivak 2y ago
    Huh? You can create partitions in ways other than issues with the underlying network. You can mess up firewall rules for example and find yourself with no quorum.
dijit 2y ago
> No, you can have availability and consistency as long as you have enough replicas. You've misunderstood the problem. You cannot be consistent if you cannot resolve conflicts, taking writes after a network partition means you are operating on stale data. Honestly the closest we've ever gotten to solving CAP theorum is spanner[0], which trades off availability by being hugely less performant for writes. I'm aware spanner is used a lot in google cloud (under the hood), but you won't solve CAP by having hundreds of PGSQL replicas, because those aren't using Spanner. In fact, you can test it out, ElasticSearch orchestrates a huge number of lucene databases, a small install will have a dozen or so replicas and partitions, but you're welcome to crank it to as many nodes as you want then split off a zone, and see what happens. I'm becoming annoyed at the level of ignorance on display in this thread, so I'm sorry for the curt tone, you can't abstract your way to solving it, it's a fundamental limitation of data. [0]: https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf https://static.googleusercontent.com/media/research.google.c...
- cryptonector 2y ago
  Did you read TFA? Please, the point of TFA is NOT that you don't need distributed consensus algorithms, but that once you have them you don't need to worry about partitions, therefore you can have consistency, and you get "availability" in that the cloud "is always available", and if that sounds like cheating you have to realize that partitions in the cloud don't isolate clients outside the cloud, only servers inside the cloud, and if there's no quorum anywhere then you just treat that as "the cloud is down".
  - dijit 2y ago
    I did, and it doesn't provide insight that didn't exist 15 years ago. Cloud is always available? I have a bridge to sell you.
  - robertlagrant 2y ago
    > you get "availability" in that the cloud "is always available", The cloud isn't what's being described as available. The service is available or not. The service is hosted on multiple computers that talk to each other. If they stop talking to each other, the service needs to either become unavailable (choosing consistency) or risk having not up to date data (choosing availability).

kstrauser 2y ago

That presumes you can only have 1 partition at a time. That is not the case. You can optimize for good behavior when you end up with 2 disconnected graphs. It’s absolutely the case that a graph with N nodes can end up with N separate groups. Conceptually, imagine a single switch that connects all of them together and that switch dies. You can engineer cloud services to be resilient. AWS has done a great job of that in my personal experience. But worst cases can still happen. If you have an algorithm that runs in n*log(n) most of the time but 2^n sometimes, it can still be super useful. You have to prepare for the bad case though. If you say it’s been running great so far and we don’t worry about it, fine, but that doesn’t mean it can’t still blow up when it’s most inconvenient. It only means it hasn’t yet.

cryptonector 2y ago
Again, a partition that leaves you with no quorum anywhere is like the cloud being down.
- pessimizer 2y ago
  A partition that leaves you with no quorum anywhere is like the cloud being down if you value consistency over availability.
  - cryptonector 2y ago
    Yes, but again, TFA says that you will trust the cloud will be up long enough that you would indeed prefer consistency. My goodness. So many commenters here today are completely ignoring TFA and giving lessons on CAP -- lessons that are correct, but which completely ignore that TFA is really arguing that clouds move the needle hard in one direction when considering the CAP trade-offs, to the point that "the CAP theorem is irrelevant for cloud systems" (which was this post's original title, though not TFA's).
    - pyrale 2y ago
      The issue people are pointing is that the author conflates "Cloud is good enough for my needs" with "CAP is no longer relevant".The point is especially annoying considering that the author works at a cloud vendor and not a cloud user.
- robertlagrant 2y ago
  > Again, a partition that leaves you with no quorum anywhere is like the cloud being down. What does this mean? What is the cloud being down? The cloud isn't a single thing; it's lots of computers in lots of data centres.
  - NavinF 2y ago
    It means there will be an article on the front page declaring the outage
- Spivak 2y ago
  Huh? You can create partitions in ways other than issues with the underlying network. You can mess up firewall rules for example and find yourself with no quorum.

dijit 2y ago

> No, you can have availability and consistency as long as you have enough replicas. You've misunderstood the problem. You cannot be consistent if you cannot resolve conflicts, taking writes after a network partition means you are operating on stale data. Honestly the closest we've ever gotten to solving CAP theorum is spanner[0], which trades off availability by being hugely less performant for writes. I'm aware spanner is used a lot in google cloud (under the hood), but you won't solve CAP by having hundreds of PGSQL replicas, because those aren't using Spanner. In fact, you can test it out, ElasticSearch orchestrates a huge number of lucene databases, a small install will have a dozen or so replicas and partitions, but you're welcome to crank it to as many nodes as you want then split off a zone, and see what happens. I'm becoming annoyed at the level of ignorance on display in this thread, so I'm sorry for the curt tone, you can't abstract your way to solving it, it's a fundamental limitation of data. [0]: https://static.googleusercontent.com/media/research.google.com/en//archive/spanner-osdi2012.pdf https://static.googleusercontent.com/media/research.google.c...

cryptonector 2y ago
Did you read TFA? Please, the point of TFA is NOT that you don't need distributed consensus algorithms, but that once you have them you don't need to worry about partitions, therefore you can have consistency, and you get "availability" in that the cloud "is always available", and if that sounds like cheating you have to realize that partitions in the cloud don't isolate clients outside the cloud, only servers inside the cloud, and if there's no quorum anywhere then you just treat that as "the cloud is down".
- dijit 2y ago
  I did, and it doesn't provide insight that didn't exist 15 years ago. Cloud is always available? I have a bridge to sell you.
- robertlagrant 2y ago
  > you get "availability" in that the cloud "is always available", The cloud isn't what's being described as available. The service is available or not. The service is hosted on multiple computers that talk to each other. If they stop talking to each other, the service needs to either become unavailable (choosing consistency) or risk having not up to date data (choosing availability).