CAP theorem

CAP states that during a network partition a distributed system cannot simultaneously provide linearizable consistency and full availability for both reads and writes — you choose CP or AP behavior for that window. In practice partitions are rare but real; most systems are PA with tunable consistency.

Use CAP to frame discussion, not to avoid specifics. Ask which invariant breaks during partition: stale reads, write unavailability, or conflict resolution. Modern systems offer consistency levels per operation.

On interviews: explain partition scenario for your database choice, avoid "CAP means pick two forever," and tie answer to a concrete user-visible invariant.

Common pitfalls: reciting CAP without mapping to the design; ignoring latency as a practical consistency factor; assuming partitions never happen in one cloud region.

The trade-off is flexibility versus complexity—know when the simpler path is enough.

Checklist:

• Describe behavior under network partition.
• Name CP versus AP trade for your store.
• Link to concrete consistency requirement.
• Mention tunable or session consistency options.