CAP Basics
CAP Properties
- Consistency: All nodes see the same data at the same time; not the same as ACID consistency.
- Availability: Every request to a non-failing node receives a response, possibly stale.
- Partition Tolerance: System continues despite message loss or network partitions between nodes.
Interview Decision
Prefer availability by default
Default for most designs; stale data is acceptable when inconsistency is not catastrophic.
Ask latest-read question
Ask: "Does every read need to read the most recent write?".
Treat partitions as mandatory
Network failures will happen; choose consistency or availability during a partition.
Choose Consistency
- Ticket Booking Systems: Prevent two users from booking the same seat during a partition.
- E-commerce Inventory: Avoid showing one remaining item as available to multiple users.
- Financial Systems: Stock trading platforms need accurate order books; stale data can cause wrong-price trades.
Choose Availability
- Social Media: Old profile pictures for a few minutes are acceptable.
- Content Platforms: Old movie descriptions are acceptable temporarily.
- Review Sites: Slightly outdated restaurant hours briefly are better than no information.
Design Impact
Consistency Patterns
- Distributed Transactions: Use two-phase commit to keep cache and database in sync; adds complexity and latency.
- Single-Node Solutions: One database instance avoids propagation issues but limits scalability.
Availability Patterns
- Multiple Replicas: Serve reads from replicas; asynchronous replication improves availability with possible staleness.
- Change Data Capture (CDC): Propagate primary database changes asynchronously to replicas, caches, and other systems.
Technology Choices
- Traditional RDBMSs: PostgreSQL and MySQL fit consistency-prioritized designs.
- Google Spanner: Technology choice when prioritizing consistency.
- DynamoDB: Configurable for either priority based on chosen mode.
- Cassandra: Technology choice when prioritizing availability.
- Redis Clusters: Technology choice when prioritizing availability.
Advanced Choices
Feature Choices
- Ticketmaster: Consistency for booking seats; availability for viewing event details.
- Tinder: Consistency for matching; availability for viewing profiles.
Consistency Models
- Eventual Consistency: Default behavior of most distributed databases; consistency returns over time.
- Strong Consistency: All reads reflect the most recent write; most expensive but needed for absolute accuracy.
- Causal Consistency: Related events appear in the same order to all users.
- Read-your-own-writes Consistency: Users see their own updates immediately; others may see older versions.
Your account is free and you can post anonymously if you choose.