What is CAP Theorem?
The CAP theorem states that a distributed system can provide only two of three guarantees simultaneously:
- Consistency (C): All nodes see the same data at the same time
- Availability (A): Every request receives a response
- Partition Tolerance (P): System continues operating despite network failures
┌─────────────────┐
│ CAP Theorem │
└────────┬────────┘
│
┌─────────────────┼─────────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ CA │ │ CP │ │ AP │
│Consistency│ │Consistency│ │Availability│
│Availability│ │ Partition │ │ Partition │
│ │ │ Tolerance │ │ Tolerance │
└──────────┘ └──────────┘ └──────────┘
RDBMS MongoDB, Cassandra,
HBase DynamoDBUnderstanding the Three Properties
Consistency
typescript
// Strong consistency
const user = await db.getUser(1);
// All nodes return same data
// Example: Banking system
// Account balance must be consistent
// across all nodesAvailability
typescript
// Always respond, even with stale data
try {
const user = await db.getUser(1);
return user;
} catch (error) {
// Fallback to cached data
return cache.get(1);
}Partition Tolerance
typescript
// System works despite network failures
// Node A can't reach Node B
// Both continue serving requests
// Sync when connection restoresCAP Trade-offs
CA Systems
typescript
// Consistency + Availability
// No partition tolerance
// Single-node systems, traditional RDBMS
class UserService {
async getUser(id: string) {
// Always returns consistent data
return this.db.findOne({ id });
}
async updateUser(id: string, data: any) {
// Blocks until written
return this.db.update({ id }, data);
}
}CP Systems
typescript
// Consistency + Partition Tolerance
// May sacrifice availability
// MongoDB, HBase, Redis
class CPUserService {
async getUser(id: string) {
// Must reach majority of nodes
const quorum = await this.getQuorum();
return quorum.find({ id });
}
async updateUser(id: string, data: any) {
// May fail if partition occurs
const quorum = await this.getQuorum();
return quorum.update({ id }, data);
}
}AP Systems
typescript
// Availability + Partition Tolerance
// May sacrifice consistency
// Cassandra, DynamoDB, CouchDB
class APUserService {
async getUser(id: string) {
// Return from any available node
return this.anyNode.find({ id });
}
async updateUser(id: string, data: any) {
// Write to available nodes
// Sync asynchronously
return this.anyNode.update({ id }, data);
}
}Practical Examples
E-commerce Platform
typescript
// Product catalog: AP (Available, eventually consistent)
// Shopping cart: AP (Always available)
// Payment processing: CP (Consistent transactions)
// User profile: AP (Available, eventually consistent)Social Media
typescript
// Posts: AP (High availability, eventual consistency)
// Likes: AP (Counter, eventual consistency fine)
// Notifications: AP (Delivery more important than consistency)
// User authentication: CP (Security requires consistency)Best Practices
- 1Choose based on use case
- 2Consider eventual consistency for AP
- 3Use quorum for CP systems
- 4Implement fallback mechanisms
- 5Monitor trade-offs in production
Conclusion
CAP theorem forces hard choices. Understand your requirements and choose the right combination of consistency, availability, and partition tolerance.
Design systems based on your specific needs!