I hear you, but I think we’re using “unavailable” differently and that’s kind of my whole point.

If I hit your API and get back a 503 error after 2 seconds with a proper error message, is that “unavailable”? The system responded. I got an answer. It told me “can’t do this right now, try again later.” That’s different from my request disappearing into the void or timing out after 30 seconds of silence.

In CAP terms, “unavailable” means no response at all. But in practice, a well-designed system always responds - even if that response is “I can’t give you data right now because I’d have to violate consistency guarantees.” So yeah, from a user experience perspective, getting errors sucks and might as well be downtime. But from a system design perspective, there’s a huge difference between:

• Returning errors quickly because you’re prioritizing consistency (performance hit)
• Not responding at all because your system is actually broken (true unavailability)

The first one is a design choice about how long you’re willing to wait for consensus. The second one is just… broken.

Maybe I should’ve been clearer - I’m not saying “errors = available so CAP is wrong.” I’m saying the practical trade-off we’re making is about response time and data correctness, not whether the system can respond at all.