It's not all or nothing, and it's not about the downtime. It has everything to do with what guarantees you need about your data. It turns out, there are various

It's not all or nothing, and it's not about the downtime. It has everything to do with what guarantees you need about your data. It turns out, there are various levels of consistency (strict, sequential, linearizable, etc), and the stronger the guarantees you need, both the harder it is to enforce at a system-wide level, AND the harder it is to have high throughput (both in the 'happy' case, and in any sort of negative event). It's not a question, really, of "choosing" to be CP, but instead to figure out where on a spectrum of consistency vs availability you want to fall (and then that shade will fall into the 'consistent' or 'available' camp, as generally understood). Sometimes it's okay to just accept a best attempt at a write (such as a cache). Sometimes you REALLY need to ensure ONE view of the truth across the entire system (such as banking). Most cases fall somewhere in the middle, you can make tradeoffs. For instance, user metadata stores are great cases for eventual consistency. Very unlikely to get conflicts (a user isn't generally updating their data in two different locations), but could be fairly high throughput on reads; relaxing your consistency guarantees makes sense (easier to implement, fewer resources needed to maintain invariants, and allows for higher availability in the event of a partition).