3 ms·

I think the CAP theorem is a bit overstated. It’s not, “You can’t have a perfect system,” but “You can’t have a system which is both available and consistent du

I think the CAP theorem is a bit overstated. It’s not, “You can’t have a perfect system,” but “You can’t have a system which is both available and consistent during a network partition.” True, and interesting, and useful to know, but if “100% available” is in your requirements to begin with, you are doomed to fail and the CAP theorem is just more nails in the coffin. To me, the “you can’t have a perfect system” is really just, “You can’t have 100% availability, and you can’t have 100% durability either.” The hard part is then convincing the users of your system that even though your system seems perfect, they should be prepared for it to fail. IMO the backend API solution is somewhat easy. 503 Service Unavailable. Then the front-end needs to somehow present a meaningful error message to the user, with a plan for how the user can accomplish their desired action or at least save their state and try continuing later… which can get insanely complicated…

majormajor 5y ago
If your backend is frequently throwing 500 errors and "convince the users of your system that this is OK" flies with your management, sure, backend is easy! But that's often not the requirement... 100% available isn't the requirement per se either, but "as available as possible because outages cost us $XXXX/minute" is. And pushing that number up is HARD. And remember the context of this thread: we have a claim here that backend IS easy and that it CAN be "100% correct and bug free." Saying this allows for random-ass 500 errors whenever stuff is broken is such a huge copout as to make that original claim meaningless.
- klodolph 5y ago
  > If your backend is frequently throwing 500 errors and "convince the users of your system that this is OK" flies with your management, sure, backend is easy! Strawman argument. I think you’re responding to something I didn’t write. The argument is kind of absurd. > …but "as available as possible because outages cost us $XXXX/minute" is. “As available as possible” is not a reasonable requirement. If this is your requirement, you’re in deep shit, but for different reasons. The problem is that you can generally spend more money to get more uptime. At some point, you have to say that the cost of more uptime is too dear. You can do experiments, testing, and simulation to get a more quantitative handle on the trade-off between uptime and resources spent. If you care that much, that is. But “as available as possible” is a bad requirement because there’s no way to tell if it’s satisfied. What ends up happening is that people unsatisfied with uptime can blame you for not having enough uptime, but they aren’t telling you how much is enough. The purpose of having a requirement is to record an agreement between different teams about “how much uptime is enough uptime”. It can be the wrong number, and it can be revisited, but if it’s not a number (with a way to measure it), you won’t be able to calculate other numbers like “how many database replicas do I need?” > And remember the context of this thread… I’m responding to the CAP theorem bit. You said that the CAP theorem means, “you can't have a perfect system here, you have to choose”, and I think that this is misstating the CAP theorem. > Saying this allows for random-ass 500 errors whenever stuff is broken is such a huge copout as to make that original claim meaningless. 503 errors aren’t random. They happen when the backend is unavailable. It’s not a random “stuff is broken” error—that’s 500. This is not a cop-out. Services will sometimes be unavailable. The 503 status is the correct way to signal this to the front-end. The fact that the back-end returns a 5xx series error code does not mean that there is a bug in the back-end. Likewise, if the service is important enough, your front-end should be able to respond to a 503 error with some kind of reasonable workflow for the user.

majormajor 5y ago

If your backend is frequently throwing 500 errors and "convince the users of your system that this is OK" flies with your management, sure, backend is easy! But that's often not the requirement... 100% available isn't the requirement per se either, but "as available as possible because outages cost us $XXXX/minute" is. And pushing that number up is HARD. And remember the context of this thread: we have a claim here that backend IS easy and that it CAN be "100% correct and bug free." Saying this allows for random-ass 500 errors whenever stuff is broken is such a huge copout as to make that original claim meaningless.

klodolph 5y ago
> If your backend is frequently throwing 500 errors and "convince the users of your system that this is OK" flies with your management, sure, backend is easy! Strawman argument. I think you’re responding to something I didn’t write. The argument is kind of absurd. > …but "as available as possible because outages cost us $XXXX/minute" is. “As available as possible” is not a reasonable requirement. If this is your requirement, you’re in deep shit, but for different reasons. The problem is that you can generally spend more money to get more uptime. At some point, you have to say that the cost of more uptime is too dear. You can do experiments, testing, and simulation to get a more quantitative handle on the trade-off between uptime and resources spent. If you care that much, that is. But “as available as possible” is a bad requirement because there’s no way to tell if it’s satisfied. What ends up happening is that people unsatisfied with uptime can blame you for not having enough uptime, but they aren’t telling you how much is enough. The purpose of having a requirement is to record an agreement between different teams about “how much uptime is enough uptime”. It can be the wrong number, and it can be revisited, but if it’s not a number (with a way to measure it), you won’t be able to calculate other numbers like “how many database replicas do I need?” > And remember the context of this thread… I’m responding to the CAP theorem bit. You said that the CAP theorem means, “you can't have a perfect system here, you have to choose”, and I think that this is misstating the CAP theorem. > Saying this allows for random-ass 500 errors whenever stuff is broken is such a huge copout as to make that original claim meaningless. 503 errors aren’t random. They happen when the backend is unavailable. It’s not a random “stuff is broken” error—that’s 500. This is not a cop-out. Services will sometimes be unavailable. The 503 status is the correct way to signal this to the front-end. The fact that the back-end returns a 5xx series error code does not mean that there is a bug in the back-end. Likewise, if the service is important enough, your front-end should be able to respond to a 503 error with some kind of reasonable workflow for the user.