Weak consistency use cases (why ever use it)?

Question

CP = Every read receives the most recent write or an error.

Weak consistency = After a write, reads may or may not see it. A best effort approach is taken.

(source)

If I understand correctly, In CAP theorem, we have the tradeoff between availability(AP) and consistency(CP), so we must chose between them.

Weak consistency is a consistency pattern, so in order to implement it, I'll need to pass on availability.

But the pattern definition declares 'best effort', meaning it cannot validate 'receives the most recent write' principle.

So my question is - Why ever use it? what is the use case where i'll choose best effort consistency over availability?

Answer 1

CAP theorem indicates that during a network partitioning how your system as whole should behave:

• either be consistent but not highly available
• or be available but not strongly consistent

(Source)

AP

Even though there is a temporal network partitioning, which prevents proper synchronization / replication between the nodes, you still allow new write operations. So, some node might have newer values than others. From a consumer perspective this means that two subsequent reads might return different values.

CP

Even though there is a temporal network partitioning, which prevents proper synchronization / replication between the nodes, you allow only read operations or nothing. Whether your system supports degraded mode or not you can switch to read-only mode or you become (as a system) entirely unavailable.

AP vs. CP after the network issue

• In case of AP you need to perform a syncronization between the nodes after the network partitioning is fixed
• In case of CP you can re-perform the write operations after the network partitioning is fixed

Different NOSQL database systems prefer Availability (like Cassandra, DynamoDb) while others Consistency (like Redis, MongoDb). Depending on your requirements you have to choose the right database system to support your needs.

Answer 2

You can have strong consistency by paying the cost which is communication. In a strongly consistent system you need to totally order all client requests which require a lot of communication (Think about Paxos or PBFT).

But, some applications do not need strong consistency, and in this case why you should pay the cost of communication?

In this context communicating more means an increase in the latency of replying client requests.

Example-1: If you are a bank, and you are cliearing transactions. In this case you would like to have strong consistency. Otherwise, you might have financial loses.

Example-2: Assume that you are a blogging system, and writers can publish blog entries, and later they can edit them. If a writer edits his entry but some of the users see an old version of it rather than the newest version. I guess it is not the end of the world, and it does not have any other implication.

Thefore, if your application needs strong consistency, you should have it. Otherwise, having it might increase the latency of client requests without any use.