CAP Theorem: The CAP theorem states that a distributed system can only guarantee two out of three properties: Consistency, Availability, and Partition Tolerance.
(C)onsistency - every read operation receives the most recent write or an error. In simpler terms, all clients see the same data at the same time, regardless of which node they connect to.
(A)vailability - Every request received by a non-failing node in the system must result in a response, without guarantee that the response contains the most recent write. Essentially, the system is always "up" and responding to requests. An e-commerce website that needs to handle a massive surge in traffic during a flash sale might prioritize availability. Even if some data is temporarily slightly out of date (e.g., inventory counts), it's more important that the site stays online and allows users to make purchases.
(P)artition Tolerance - The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes: "partition" is essentially a break in communication between different parts of the system. In real-world distributed systems, network partitions are inevitable. Therefore, partition tolerance is often considered a must-have.
During a network partition (which is assumed to be inevitable), you have to choose between Consistency and Availability.
You can't have both simultaneously because if parts of the system can't communicate, you either have to:
>Stop serving requests from some parts to maintain consistency (sacrificing Availability).
>Continue serving requests from all parts, potentially with stale data (sacrificing Consistency).
If you have a globally-distributed financial application that must never return stale data, you are strongly emphasizing Consistency (C). Additionally, since the application is globally distributed, network partitions (P) are essentially inevitable and cannot be ignored. Thus, you must also support Partition Tolerance (P).