Explain the CAP theorem and how it applied to a system you have worked on.

CAP says that when a network partition splits your nodes, you must choose between consistency and availability. You cannot opt out of partition tolerance, because networks fail whether you plan for it or not. So the real question is what your system does during a partition: refuse writes to stay correct, or accept them and reconcile later. Outside a partition you can have both, which is why latency is the everyday trade.

The framing I use is that partition tolerance is not a choice, because packets get dropped and switches fail regardless of my architecture. So CAP is really asking what the system does while it is split: refuse the write so nobody reads stale data, or take the write and sort it out afterwards. What I like about the PACELC extension is that it names the part you deal with every day, which is that even when everything is healthy you are trading latency against consistency, because a quorum write across regions costs round trips. On a product I worked on we split it by feature. Anything touching billing went through the primary with a read after write guarantee, because charging somebody twice is not recoverable with an apology. The activity feed read from replicas and could be a few seconds behind, and nobody ever noticed. Same system, two answers, chosen per feature rather than as an architectural religion.