CAP Theorem Explained
The CAP theorem states that any distributed data store can only guarantee two of three properties simultaneously: Consistency, Availability, and Partition tolerance. Network partitions are unavoidable in real systems, so the practical choice is between CP and AP architectures. This recipe walks through what each property means, why partition tolerance is non-negotiable, and how to reason about tradeoffs when designing Meridian pipelines.
1.Consistency
Every read returns the most recent write or an error. In a strongly consistent system, all clients see the same data at the same time, regardless of which node they connect to. Achieving this requires coordination between replicas, usually via consensus protocols like Raft or Paxos, which adds latency and reduces throughput.
2.Availability
Every request receives a non-error response, even if it is not the most recent write. High availability systems accept stale reads in exchange for never refusing a request. DNS and Cassandra default to this posture: the system stays up under load, but clients may observe diverging values across nodes until replication catches up.
3.Partition Tolerance
The system continues to operate despite arbitrary message loss between nodes. Networks fail, packets drop, and TCP connections die. Any real distributed system must tolerate partitions, which means the actual tradeoff during a partition is between consistency and availability.
// CP example: refuse writes during partition
async function writeCP(key, value) {
const quorum = await acquireQuorum();
if (!quorum) throw new Error('partition');
return quorum.commit(key, value);
}
// AP example: accept writes, reconcile later
async function writeAP(key, value) {
await localReplica.put(key, value);
scheduleAntiEntropy(key);
return { ok: true, stale: maybe };
}