CAP Theorem (Brewer's Theorem)

Le CAP Theorem (Brewer, 2000 ; formalisé Gilbert et Lynch 2002) est un résultat fondamental des systèmes distribués stating qu'un système distribué ne peut garantir simultanément qu'au maximum 2 des 3 propriétés : Consistency, Availability, Partition tolerance.

(1) **Consistency** (C) — tous les nodes voient les mêmes données au même moment (linearizability strong consistency).

(2) **Availability** (A) — chaque requête reçoit une réponse (success ou failure) — pas de blocage.

(3) **Partition tolerance** (P) — système continue fonctionner malgré perte de messages réseau entre nodes.

En pratique : sur Internet, partitions réseau sont inévitables, donc P est obligatoire. Le vrai choix est entre **CP** (sacrifice availability pendant partition) ou **AP** (sacrifice consistency pendant partition).

Exemples systèmes :
- **CP** : MongoDB single-master, HBase, Redis Sentinel, etcd, Consul, Zookeeper — choisissent rejet de requests vs returning stale data.
- **AP** : Cassandra, DynamoDB (par défaut), Riak, CouchDB — toujours répondent même si stale data ou conflits.
- **CA** seul possible si pas de partition (single-node ou tightly coupled cluster) — RDBMS classiques.

Nuances modernes :
(1) **PACELC theorem** (Abadi 2012) — extension : en présence de Partition, choose A or C ; ELSE (no partition), choose Latency or Consistency. Plus complet.
(2) **CRDTs** — Conflict-free Replicated Data Types — permettent merge automatique consistant après partition (used in Riak, Redis CRDTs, Yjs collaborative editing).
(3) **Tunable consistency** — Cassandra/DynamoDB permettent ajuster par-request (R+W>N pour strong consistency selon Quorum).
(4) **Distributed SQL** (Spanner, CockroachDB) — strong consistency via Paxos avec latency cost.

Décision pratique : utiliser AP pour high-scale availability-critical (e-commerce browse, social feeds), CP pour money/inventory/critical state (banking, ticketing). Compétences DEA-C01, DP-203.