Partition Tolerance

Partition Tolerance est la capacité d'un système distribué à continuer fonctionner correctement même quand des partitions réseau (perte de communication entre certains nodes) surviennent. C'est l'un des 3 éléments du CAP theorem, et en pratique sur réseaux réels, c'est non-négociable.

Pourquoi mandatory : (1) réseaux modernes failent inévitablement (link down, switch crash, DC isolation, transient packet loss massive) ; (2) latence cross-region peut simuler partition ; (3) sans P, single node failure peut bring down entire system. Sur Internet ou réseaux WAN, partitions sont quand pas si.

Que se passe-t-il pendant partition : le système split en 2+ groupes ("split brain"). Chaque groupe peut continuer servir requests mais avec différents trade-offs :

- **CP systems** — minorité partition becomes unavailable (refuse writes) pour préserver consistency. Majority continue. Au heal, minority rejoint et catche up. Exemples : ZooKeeper, etcd, Consul (Raft), MongoDB CP mode.

- **AP systems** — chaque partition continue accepter writes, divergence possible. Au heal, conflicts must be resolved (last-write-wins, vector clocks, CRDTs, application-level resolution). Exemples : Cassandra, DynamoDB, Riak.

Détection partition : (1) heartbeats ; (2) timeouts (false positives possibles) ; (3) consensus protocols (Raft, Paxos) — votes majority pour qui est "alive" ; (4) gossip protocols (Cassandra).

Mitigation : (1) **Quorum** — require N/2+1 nodes pour writes (Cassandra QUORUM consistency level, etcd Raft) ; (2) **Multi-region replication** avec latency-aware (DynamoDB Global Tables, Cosmos DB) ; (3) **Eventual consistency** + conflict resolution ; (4) **Chaos engineering** — Netflix Chaos Monkey simule partitions pour test resilience.

Real-world examples : 2017 AWS S3 us-east-1 outage (configuration partition), 2021 Facebook BGP outage (essentially mass partition), regular cloud regional issues. Designing for partition tolerance = engineering reality. Compétences DEA-C01, SAA-C03.