CAP Theorem in Practice
The CAP theorem states that a distributed system can provide at most two of three guarantees: Consistency (every read receives the most recent write), Availability (every request receives a response), and Partition tolerance (the system continues to operate despite network partitions). Since network partitions are inevitable in distributed systems, the real choice is between consistency (CP) and availability (AP) during a partition.
CAP theorem is a pizza delivery trilemma: Consistent (every branch has the exact same menu), Available (every branch always answers the phone), Partition-tolerant (branches keep working even if the phone line between them is cut). You can only guarantee two. Since phone lines DO get cut, you choose: same menu everywhere (CP) or always answer the phone (AP).
In practice, CAP is not a binary choice — it is a spectrum. PostgreSQL with synchronous replication is CP: during a partition, the primary refuses writes if it cannot reach the synchronous replica. DynamoDB defaults to AP: during a partition, both sides continue accepting writes with eventual consistency reconciliation. However, DynamoDB also offers strongly consistent reads (CP behavior for reads) at 2x the cost. Cassandra lets you tune consistency per query: QUORUM reads/writes give you strong consistency at the cost of latency, ONE gives you availability. The PACELC theorem extends CAP: when there is no Partition, you still trade Latency for Consistency. Spanner and CockroachDB choose consistency even without partitions, paying a latency tax for distributed consensus on every write.
Real-world implications: most web applications should default to strong consistency (PostgreSQL) and only introduce eventual consistency for specific features that need it (like social media feed ranking, where showing a slightly stale feed is acceptable). The distributed systems that successfully use eventual consistency (DynamoDB, Cassandra) provide conflict resolution mechanisms: last-writer-wins (LWW), vector clocks, or application-level merge functions. CRDTs (Conflict-free Replicated Data Types) enable automatic conflict resolution for specific data structures (counters, sets, registers) without coordination. The key insight for interviews: do not treat CAP as a theoretical exercise. State which consistency model you need for each data access pattern and choose the database that provides it. A payment system needs strong consistency (PostgreSQL). A view counter can use eventual consistency (Redis, Cassandra).
I apply CAP practically rather than theoretically. For each data access pattern, I decide: does this need strong consistency or is eventual consistency acceptable? Payment processing, inventory management, and user authentication need strong consistency — I use PostgreSQL. View counts, activity feeds, and recommendation scores can tolerate eventual consistency — I use Redis or DynamoDB. When using eventually consistent systems, I design for it explicitly: idempotent writes, read-your-writes routing to the primary, and conflict resolution strategies. The PACELC extension is more useful than pure CAP: even without partitions, there is always a latency-consistency trade-off in distributed systems.
Treating CAP theorem as a reason to avoid consistency. Some engineers use 'we need to be available' as justification for choosing eventually consistent databases when their use case actually requires strong consistency. A shopping cart that loses items or a bank account that shows the wrong balance is not acceptable availability — it is a bug. Default to strong consistency and relax it only when the business logic truly permits it.