| |
| ▲ | btown 4 days ago | parent | next [-] | | https://tqdev.com/2024-the-p-in-cap-is-for-performance is a really interesting take on this as a response to https://blog.dtornow.com/the-cap-theorem.-the-bad-the-bad-th... - essentially, the only way to get CA is if you're willing to say that every request will succeed eventually, but it might take an unbounded amount of time for partitions to heal, and you have to be willing to wait indefinitely for that to happen. Which can indeed make sense for asynchronous messaging, but not for real-time applications as we think about them in the modern day. In practice, if you're talking about CAP for high-performance systems, you're choosing either CP or AP. | |
| ▲ | rhaen 4 days ago | parent | prev [-] | | Well, P isn't really much of a choice, I don't think you can opt out of acts of god. | | |
| ▲ | fwip 4 days ago | parent [-] | | You can design to minimize P, though. For instance, if you have all the services running on the same physical box, and make people enter the room to use it instead of over the Internet, "partition" becomes much less likely. (This example is a bit silly.) But you're right, if you take a broad view of P, the choice is really between consistency and availability. | | |
| ▲ | paulddraper a day ago | parent [-] | | Yes. P is kinda fundamental to your setup. For example, running S3 locally or not. |
|
|
|
