Kubernetes uses etcd (a distributed key-value store using Raft) to elect a leader and maintain strong consistency for cluster state configurations across master nodes.
Visual representation of control loops, memory layout, and execution flow for CAP Theorem, PACELC & Raft Consensus.
When cluster boots or leader heartbeat times out, nodes transition to Candidate state and request votes.
Client writes to Leader; Leader appends entry to its local log and broadcasts AppendEntries RPCs.
Once majority of follower nodes acknowledge writing log entry, Leader commits entry and responds to client.
| Feature / Dimension | CP System (Consistency + Partition Tolerance) | AP System (Availability + Partition Tolerance) |
|---|---|---|
| Network Partition Behavior | Rejects writes/reads if majority quorum cannot be reached (Prioritizes Data Correctness) | Returns stale or conflicting data rather than failing (Prioritizes Availability) |
| Example Databases | PostgreSQL HA, etcd, HBase, CockroachDB | Apache Cassandra, Amazon DynamoDB, Couchbase |
Detailed answers, interviewer pro tips, key takeaway summaries, and code examples formulated for technical rounds.
✅ Correction: Network partitions (dropped cables, router crashes) are inevitable; in distributed systems, "P" is mandatory, so the real choice is CP vs AP.
Architectural trade-offs and consensus protocols across network nodes.