Master Consistency, Availability, and Partition Tolerance with Fun!
Definition: All nodes show the same data at the same time. Every read gets the latest write or an error.
Example: A bank account shows $300 on all platforms (app, ATM, web) after a $200 transfer.
Definition: The system remains operational and responds to all requests, even if data isnβt the latest.
Example: A banking app responds at 2 AM, even during maintenance, never showing βService Unavailable.β
Definition: The system continues to operate despite network failures between nodes.
Example: Servers in different cities lose connection, but users can still access local data.
Sacrifice: Availability
Use Case: Banking, Financial systems
Examples: MongoDB, Redis, HBase
Sacrifice: Consistency
Use Case: Social media, Content delivery
Examples: Cassandra, DynamoDB, CouchDB
Sacrifice: Partition Tolerance
Use Case: Single-node or local networks
Examples: PostgreSQL, MySQL (single node)
System Type | CAP Choice | Example | Business Impact | Trade-off Justification |
---|---|---|---|---|
Banking Systems | CP | Account balances, transactions | Accurate data is critical | Better to pause than show incorrect data |
Social Media | AP | Social posts, feeds | Prioritizes user engagement | Users tolerate slightly outdated posts |
E-commerce Catalog | AP | Product listings | Uninterrupted shopping experience | Slightly outdated info is acceptable |
Stock Trading | CP | Real-time stock prices | Accuracy prevents financial loss | Trading halts better than wrong prices |
Content Management | CA | Corporate wikis | Reliable in controlled networks | Partitions rare in local networks |
In a healthy network, all three properties (Consistency, Availability, Partition Tolerance) can be maintained. CAP constraints apply only during partitions.
Yes, network partitions remain a challenge in modern cloud systems. CAP guides architects in designing resilient systems.
AP systems often use eventual consistency, where data syncs over time, unlike the strong consistency of CP systems.
CAP addresses distributed system behavior across nodes, while ACID focuses on transaction properties within a single database.