← Tilbage til koncepter

CAP Theorem

Teori

Fundamental teori om at distribuerede systemer kun kan garantere to af tre: Consistency, Availability, Partition Tolerance.

Beskrivelse

CAP Theorem, formuleret af Eric Brewer i 2000, siger at et distribueret database system ikke kan samtidigt garantere alle tre egenskaber: Consistency (alle nodes ser samme data samtidigt), Availability (systemet svarer altid på requests), og Partition Tolerance (systemet fungerer trods netværksopdeling). I praksis er partition tolerance ikke valgfri i distribuerede systemer - netværksfejl vil ske. Derfor må man vælge mellem CP (consistency over availability) eller AP (availability over consistency). Traditionelle SQL databaser vælger typisk CP og bliver unavailable ved network partitions for at bevare consistency. NoSQL databaser som Cassandra vælger AP og accepterer eventual consistency for at forblive available. Det er vigtigt at forstå at CAP handler om worst-case scenarier - mange systemer er både consistent og available når netværket fungerer normalt. Moderne systemer bruger ofte eventual consistency og conflict resolution for at balancere trade-offs.

Problem

Når du designer et distribueret system med data på tværs af multiple servere, kan du ikke have perfekt consistency og perfect availability samtidigt når netværket fejler. Du må træffe valg om hvilke garantier der er vigtigst.

Løsning

CAP Theorem hjælper dig med at forstå trade-offs og vælge den rigtige database baseret på dine krav. CP systemer prioriterer korrekt data, AP systemer prioriterer uptime. Vælg baseret på din use case.

Eksempel

-- CP System (Consistency + Partition Tolerance)
-- Eksempel: PostgreSQL med synchronous replication

-- Scenario: Network partition mellem primary og replica
-- Hvis primary kan ikke nå replica:
WRITE operation → BLOCKED (system venter)
-- Prioriterer consistency: Vil ikke acceptere writes der
-- ikke kan replikeres. System bliver UNAVAILABLE.

-- READ operation → Kun fra primary
-- Garanterer at du altid ser seneste data
-- Men hvis primary er nede: NO SERVICE

-----------------------------------------------------

-- AP System (Availability + Partition Tolerance)  
-- Eksempel: Cassandra, DynamoDB

-- Scenario: Network partition mellem datacenters
-- Hver side fortsætter med at acceptere requests:
WRITE operation → SUCCEEDS på begge sider
-- System forbliver AVAILABLE
-- Men nu har vi INCONSISTENT data!

READ operation → Kan returnere gamle data
-- Eventually consistent: Data synces når netværk OK

-- Conflict resolution via:
-- - Last-write-wins (timestamp)
-- - Vector clocks
-- - Application-level merge

-----------------------------------------------------

-- Real eksempel: Social media post
-- AP choice: DIT post vises straks for dig (availability)
-- men måske ikke for alle venner i 1-2 sekunder (eventual)
-- Bedre end at sige "Service unavailable"!

-- Real eksempel: Bank balance  
-- CP choice: Vis KORREKT balance eller ingen service
-- ALDRIG forkert balance - consistency er critical

Fordele

  • ✓Framework til at forstå distribuerede systemer
  • ✓Hjælper med database valg
  • ✓Bevidsthed om unavoidable trade-offs
  • ✓Guide til system design decisions
  • ✓Forklarer hvorfor eventual consistency findes

Udfordringer

  • ⚠Ofte misforstået (gælder kun ved partitions)
  • ⚠Real verden er mere nuanceret end CAP
  • ⚠Ikke en on/off switch - der er spectrum
  • ⚠Latency også vigtigt (PACELC theorem)
  • ⚠Kræver dyb forståelse for korrekt anvendelse

Anvendelsesområder

  • •Vælge mellem SQL (CP) og NoSQL (AP)
  • •Design af multi-datacenter systemer
  • •Microservices database strategi
  • •Mobile apps med offline support
  • •Evaluering af database vendors

Eksempler fra den virkelige verden

  • •Banking apps: CP (korrekt balance vigtigere end uptime)
  • •Social media feeds: AP (bedre stale data end downtime)
  • •E-commerce inventory: Hybrid (eventual consistency med safeguards)
  • •DNS: AP (bedre stale DNS end ingen DNS)
  • •Booking systemer: CP (ingen double-booking)