[peterbell_nyc]

It seems like people make this really complicated.

There will occasionally be network partitions. When there are, a given node can either respond (potentially inconsistently) or not. So you pick some balance between consistency and availability. Latency is really just a proxy for availability - as latency tends towards infinite, availability tends towards zero. Of course you can wait until the network partition is resolved and the nodes are caught up - but I think it's simpler to consider that as not being available for a period of time rather than as having a high latency at that time.

Consistency or Availability - you don't have to pick one, but the more consistent you want to be (in the case of network partitions) the less available you'll be.

[justin_hancock]

Disagree on latency, for certain classes of applications it really matters. Latency can be caused by a myriad of things, but if that thing is your means for cut over, you haven't failed to respond, you've failed to respond in a timely way. The telco space has strict latency requirements. If you have a failure which results in erratic behaviour on the network due to the database taking time to handle a node failure you aren't in a good place, it has a financial impact.

There are databases that can provide high consistency and availability.

[harkinian]

Put an SLA on the latency, and it becomes availability.

[pachico]

If your decision between Consistency and Availability has business implications, you definitely aren't making this "really complicated" but rather a business logic to adhere to.

Failing to understand the implications of one over the other is often sign of immature architecture.

[harkinian]

Was going to say, latency doesn't need to be in there.