Teorema CAP — consistenta, disponibilitate, toleranta la partitii

Teorema CAP, formulata de Eric Brewer, e fundamentul arhitecturii sistemelor distribuite. Spune ca un sistem distribuit poate oferi maxim doua din trei: consistenta, disponibilitate, toleranta la partitii. Alegerea determina totul: de la baze de date la API-uri.

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:

  1. Un client scrie pe N1: x = 5
  2. Un client citeste de pe N2: x = ?
  3. Daca vrei consistenta, N2 trebuie sa refuze sau sa astepte sincronizarea → indisponibil
  4. 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.