CAP-teoremet

Teori

Fundamental teori om at distribuerede systemer kun kan garantere to af tre: Konsistens, Tilgængelighed, Partitionstolerance.

Beskrivelse

CAP-teoremet, formuleret af Eric Brewer i 2000, siger at et distribueret databasesystem ikke samtidigt kan garantere alle tre egenskaber: Konsistens (alle noder ser samme data samtidigt), Tilgængelighed (systemet svarer altid på forespørgsler) og Partitionstolerance (systemet fungerer trods netværksopdeling). I praksis er partitionstolerance ikke valgfri i distribuerede systemer - netværksfejl vil ske. Derfor må man vælge mellem CP (konsistens over tilgængelighed) eller AP (tilgængelighed over konsistens). Traditionelle SQL-databaser vælger typisk CP og bliver utilgængelige ved netværkspartitioner for at bevare konsistens. NoSQL-databaser som Cassandra vælger AP og accepterer eventual consistency for at forblive tilgængelige. Det er vigtigt at forstå at CAP handler om worst-case scenarier - mange systemer er både konsistente og tilgængelige når netværket fungerer normalt. Moderne systemer bruger ofte eventual consistency og konfliktløsning for at balancere afvejninger.

Problem

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

Løsning

CAP-teoremet hjælper dig med at forstå afvejninger og vælge den rigtige database baseret på dine krav. CP-systemer prioriterer korrekt data, AP-systemer prioriterer oppetid. Vælg baseret på din brugscase.

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

✓Rammeværk til at forstå distribuerede systemer
✓Hjælper med databasevalg
✓Bevidsthed om uundgåelige afvejninger
✓Guide til systemdesign-beslutninger
✓Forklarer hvorfor eventual consistency findes

Udfordringer

⚠Ofte misforstået (gælder kun ved partitioner)
⚠Den virkelige verden er mere nuanceret end CAP
⚠Ikke en tænd/sluk-kontakt - der er et spektrum
⚠Latenstid er også vigtig (PACELC-teoremet)
⚠Kræver dyb forståelse for korrekt anvendelse

Anvendelsesområder

•Vælge mellem SQL (CP) og NoSQL (AP)
•Design af multi-datacenter-systemer
•Microservices databasestrategi
•Mobilapps med offline-support
•Evaluering af databaseleverandører

Eksempler fra den virkelige verden

•Banking apps: CP (korrekt saldo vigtigere end oppetid)
•Sociale medie-feeds: AP (bedre forældet data end nedetid)
•E-handel lagerbeholdning: Hybrid (eventual consistency med sikkerhedsforanstaltninger)
•DNS: AP (bedre forældet DNS end ingen DNS)
•Bookingsystemer: CP (ingen dobbeltbooking)