CAP and PACELC

CAP is a rule about what a replicated database can promise when the network between its copies breaks. If replicas can’t reach each other (a partition), each one has to choose: refuse requests until it can be sure it has the latest data (consistency), or keep answering with what it has and risk stale or conflicting results (availability). You can’t have both during the split, and since networks do fail, the popular “pick two of three” reading is misleading. PACELC adds the everyday case: even when nothing is broken, waiting for replicas to agree costs time, so systems also trade latency against consistency. It’s a vocabulary for explaining why, say, a bank ledger and a shopping cart behave differently.