While designing Distributed Systems, we always consider the below approaches according to the business use case.
Consistency — Every read receives the most recent writes or an error irrespective of from which node result is fetched.
[Note:- Let’s not assume “Consistency” of CAP and ACID are the same. ACID Consistency refers to transactions in relational DB which guarantee that the data in a DB system will be valid after the transaction, not universally consistent across all the nodes across the globe as in the case of CAP.]
Availability — Every request(i.e. read or write ) receives a response, without a guarantee that it contains the most recent version of the information.
This system achieves responsiveness through replication by duplicating data across the nodes. A system with high availability doesn’t guarantee consistency, it guarantees the write and read requests will be processed, but not that the latest write will be observed.
Partition Tolerance — The system continues to operate despite arbitrary partitioning due to network failures.
[Network aren’t reliable, so we need to support partition tolerance. We need to make the tradeoff between consistency and availability. ]
Consistency and Partition tolerance — (CP)- When a partition occurs between any two nodes, the system has to shut -down the non-consistent node until the partition is resolved. This Is referring to the system where availability is sacrificed only in the case of a network partition. We should choose this setup when our business requirements dictate atomic reads and write.
Consistency and Availability- (CA)- A system comes under CA if we use a single node DB server. However single node DB servers don’t need to deal with partition tolerance.
Relational DB (i.e. PostgreSQL) helps us to achieve CA System using replication.
Availability and Partition tolerance — (AP)- in this system, all nodes remain available but except those which are set up at the wrong end of a partition might return an older or steal data than other nodes. When the partition is resolved the AP databases re-sync the node to resolve data inconsistencies within the system. We should use this setup when our business requirements allow for some flexibility around when the data in the system synchronizes.
It is useful when we have to design a system that continues its works despite external errors(i.e. cart)
The decision between Consistency, Availability and Partition is a software trade-off.