Question presented to candidate: "What is the CAP theorem? Tell me what C, A and P actually mean, why people say you can only have two, and how it changes the way you design a real replicated database or service."
What a strong answer should cover:
- The precise statement (Brewer's conjecture in 2000, proved by Gilbert and Lynch in 2002): when the network partitions, a replicated system cannot be both linearizable (C) and available to every request (A)
- Why "pick 2 of 3" is misleading: partitions are not optional in a distributed system, so the real choice is CP or AP during a partition; with no partition you can have both
- What each choice looks like: CP rejects or blocks requests on the minority side; AP answers everywhere and must reconcile divergent data later (last-writer-wins loses updates, mergeable types such as CRDTs do not)
- PACELC: even with no partition there is a trade-off between latency and consistency, which shapes everyday design far more often than partitions do
- The choice is made per operation or per data type, not per company: inventory decrements CP, like counters and shopping carts AP
- Concrete systems with care: etcd and ZooKeeper behave CP; Dynamo-style stores lean AP but are tunable; DynamoDB lets each read choose strong or eventual
Clarifying questions expected:
- What is the data, and what does a stale or conflicting value cost the business?
- Is the system in one region or several (how likely and how long are partitions, and how far apart are replicas)?
Code / implementation expected: Optional โ a small simulation of a partition showing CP rejecting requests and AP overselling; the example does exactly that.