Distributed Systems — die harten Wahrheiten

CAP-Theorem (Brewer)

Du kannst MAX 2 von 3 haben:

• C — Consistency: alle Nodes sehen denselben Stand
• A — Availability: jede Anfrage kriegt eine Antwort
• P — Partition Tolerance: System läuft trotz Netzwerk-Splits

Da Netzwerk-Splits real sind, hast du in Praxis die Wahl: CP (z.B. MongoDB, traditionell) oder AP (z.B. Cassandra, DynamoDB). "CA ohne P" gibt es real nicht.

BASE statt ACID

• Basically Available
• Soft state
• Eventual consistency

Microservices laufen meist in BASE-Welt. Eventual Consistency = nach einer Weile sind alle Subscriber synchron, aber NICHT sofort.

Häufige Fehler

• Synchrone Cross-Service-Calls: A→B→C→D. Wenn D langsam ist, fällt alles. Lieber asynchron.
• Distributed Transactions: 2-Phase-Commit ist fragil. Saga benutzen.
• Geteilte Datenbank: wenn 2 Services dieselbe DB schreiben, ist die Trennung Illusion.
• Synchroner Health-Check-Cascade: Service A down → B down → C down → Alarm-Sturm.
• Fehlende Timeouts: Ein Aufruf ohne Timeout kann das ganze System blockieren.

Resilienz-Patterns