PACELC — CAP + Latency Tradeoffs
Extension of CAP: even when no partition exists, you still trade off Latency vs Consistency.
When to use
- When CAP alone doesn't explain system behavior under normal operations
- Evaluating DynamoDB, Cosmos DB, or Spanner tradeoffs
Tradeoffs
- Harder to explain to stakeholders than CAP
- Not universally adopted as a standard model
| System | Partition behavior | Else (normal ops) | Notes |
|---|---|---|---|
| DynamoDB | PA (Available) | EL (Low latency) | Default eventual; strong read costs more |
| Cassandra | PA (Available) | EL (Low latency) | Tunable per-operation |
| MongoDB | PC (Consistent) | EC (Consistent) | Primary-only reads by default |
| Spanner | PC (Consistent) | EC (Consistent) | TrueTime enables linearizability globally |
Gotcha: Spanner achieves PC/EC via atomic clocks and TrueTime. That's an exception requiring Google-scale infrastructure, not the norm.