9 ms·

CAP doesn't omit latency. Availability essentially is latency. PACELC only says that even during normal operation you still need to make tradeoff between avail

CAP doesn't omit latency. Availability essentially is latency. PACELC only says that even during normal operation you still need to make tradeoff between availability and latency whereas CAP only deals with a tradeoff during a partition event.

rtpg 2y ago
Availability's definition: > every request received by a non-failing node in the system must result in a response I don't believe that encodes latency Instead, here's consistency: > any read operation that begins after a write operation completes must return that value, or the result of a later write operation "after a write operation completes" feels like where latency kicks in? Because within that space you can play around with completing a write operation to get what you want.
- shepherdjerred 2y ago
  It's impossible to distinguish between high latency and unavailability. You can model unavailability as infinite latency. In a real system you can wait for a partition event to resolve itself before replying which preserves consistency at the cost of latency (availability).
  - nextaccountic 2y ago
    > In a real system you can wait for a partition event to resolve itself before replying which preserves consistency at the cost of latency (availability). This is true, but PACELC states that even if there is no partition you still have a consistency vs latency tradeoff (because the processes that guarantee consistency eat up latency in form of network roundtrips)
    - shepherdjerred 2y ago
      100%, I don't think what we're saying conflicts. There is _always_ a tradeoff between consistency and availability whether you're thinking of PAC or PACELC. PACELC just makes it explicit that this tradeoff exists whether you're partitioned or not.
tux3 2y ago
The A in CAP doesn't mean what people think it means, it has nothing to do with nodes being up, or crashes, or latency, or SLA, or any abnormal dysfunction. Availability in CAP is purely a software decision, it's an algorithmic property. Roughly speaking, it is the decision to continue accepting requests during a partition, possibly sacrificing Consistency. If your refuse requests during a partition, you conserve Consistency, and you lose Availability. If you keep accepting requests during a partition, it's the opposite. High latency is considered a partition in CAP. Any hardware error, any network trouble, any bug, crash, any unreachable machines is never an Availability issue.
- shepherdjerred 2y ago
  > If your refuse requests during a partition, you conserve Consistency, and you lose Availability. If you keep accepting requests during a partition, it's the opposite. I agree > High latency is considered a partition in CAP. Can you support this claim? I don't think this is true unless you're specifically talking about high latency between nodes rather than latency between the sender and the system.
  - tux3 2y ago
    >high latency between nodes rather than latency between the sender and the system Yes, that's what I meant. To clarify, latency between the sender and the system would still not be an availability issue, but it also wouldn't be a partition. It's just out of scope of the CAP theorem. The user might be on a bad mobile connection, but it doesn't impact the distributed system itself.
  - bearbearfoxsq 2y ago
    I think the CAP 12 Years Later [1] paper covers this aspect of what latency means versus a partition. It describes that at some point in time a designer has to decide whether nodes have waited long enough and should return a response (A) or that they should wait until (potentially forever) before a response (C)

rtpg 2y ago

Availability's definition: > every request received by a non-failing node in the system must result in a response I don't believe that encodes latency Instead, here's consistency: > any read operation that begins after a write operation completes must return that value, or the result of a later write operation "after a write operation completes" feels like where latency kicks in? Because within that space you can play around with completing a write operation to get what you want.

shepherdjerred 2y ago
It's impossible to distinguish between high latency and unavailability. You can model unavailability as infinite latency. In a real system you can wait for a partition event to resolve itself before replying which preserves consistency at the cost of latency (availability).
- nextaccountic 2y ago
  > In a real system you can wait for a partition event to resolve itself before replying which preserves consistency at the cost of latency (availability). This is true, but PACELC states that even if there is no partition you still have a consistency vs latency tradeoff (because the processes that guarantee consistency eat up latency in form of network roundtrips)
  - shepherdjerred 2y ago
    100%, I don't think what we're saying conflicts. There is _always_ a tradeoff between consistency and availability whether you're thinking of PAC or PACELC. PACELC just makes it explicit that this tradeoff exists whether you're partitioned or not.

tux3 2y ago

The A in CAP doesn't mean what people think it means, it has nothing to do with nodes being up, or crashes, or latency, or SLA, or any abnormal dysfunction. Availability in CAP is purely a software decision, it's an algorithmic property. Roughly speaking, it is the decision to continue accepting requests during a partition, possibly sacrificing Consistency. If your refuse requests during a partition, you conserve Consistency, and you lose Availability. If you keep accepting requests during a partition, it's the opposite. High latency is considered a partition in CAP. Any hardware error, any network trouble, any bug, crash, any unreachable machines is never an Availability issue.

shepherdjerred 2y ago
> If your refuse requests during a partition, you conserve Consistency, and you lose Availability. If you keep accepting requests during a partition, it's the opposite. I agree > High latency is considered a partition in CAP. Can you support this claim? I don't think this is true unless you're specifically talking about high latency between nodes rather than latency between the sender and the system.
- tux3 2y ago
  >high latency between nodes rather than latency between the sender and the system Yes, that's what I meant. To clarify, latency between the sender and the system would still not be an availability issue, but it also wouldn't be a partition. It's just out of scope of the CAP theorem. The user might be on a bad mobile connection, but it doesn't impact the distributed system itself.
- bearbearfoxsq 2y ago
  I think the CAP 12 Years Later [1] paper covers this aspect of what latency means versus a partition. It describes that at some point in time a designer has to decide whether nodes have waited long enough and should return a response (A) or that they should wait until (potentially forever) before a response (C)