Formularea teoremei
Intr-un sistem distribuit, in prezenta unei partitii de retea (P), trebuie sa alegi intre consistenta (C) si disponibilitate (A). Nu poti avea toate trei simultan.
Demonstratia informala
Fie doua noduri N1 si N2 intre care comunicatia e intrerupta:
- Un client scrie pe N1: x = 5
- Un client citeste de pe N2: x = ?
- Daca vrei consistenta, N2 trebuie sa refuze sau sa astepte sincronizarea → indisponibil
- Daca vrei disponibilitate, N2 raspunde cu o valoare veche → inconsistent
Alegerea in practica
| Sistem | Tip | Alege | Motiv | |---|---|---|---| | PostgreSQL (single) | CP | Consistenta | O tranzactie e totul | | Cassandra | AP | Disponibilitate | Scrierea nu se blocheaza | | MongoDB | CP | Consistenta | Returneaza eroare la partitie | | Redis Cluster | AP | Disponibilitate | Viteza maxima | | DynamoDB | AP | Disponibilitate | Scaling orizontal |
Extensia PACELC
Teorema CAP e incompleta — acopera doar ce se intampla in timpul unei partitii. PACELC extinde:
- Partition → alege Consistency sau Availability
- Else (fara partitie) → alege Consistency sau Latency
Exemplu: DynamoDB alege AP in partitie si AL (availability + low latency) in rest. PostgreSQL alege CP in partitie si CC (consistency over latency) in rest.
Implicatii practice
Nu exista sistem distribuit "perfect". Fiecare alegere are consecinte:
- CP: Tranzactii sigure, dar potential timeout-uri la scari mari
- AP: Mereu disponibil, dar posibile valori invechite
- CA: Posibil doar daca renunti la distribuire (single node)
Alegerea corecta depinde de cerintele de business: banii prefera CP, social media prefera AP.