Die wichtigsten Patterns
Pub/Sub
Publisher sendet Event auf Topic. Beliebige Subscriber konsumieren. Standard-Modell.
Choreography vs. Orchestration
| Choreography | Orchestration |
|---|---|
| Jeder Service entscheidet selbst, wann er reagiert | Zentraler Orchestrator (z.B. Workflow-Engine) ruft Services in Reihenfolge auf |
| Lose gekoppelt, aber schwer durchschaubar | Klare Übersicht, aber Single Point of Coordination |
Saga-Pattern (für lange Transaktionen)
Klassische DB-Transaktion gibt's in Microservices nicht. Stattdessen: Saga = Folge von lokalen Transaktionen pro Service. Wenn ein Schritt scheitert → Compensating Actions in umgekehrter Reihenfolge.
1. ReserveInventory OK → CompensateInventory (release) 2. ChargePayment FAIL → rollback Schritt 1
CQRS — Command Query Responsibility Segregation
Lesen und Schreiben getrennt:
- Command-Side: empfängt Schreibanfragen, validiert, persistiert
- Query-Side: optimiert für Lesen — denormalisierte Read-Models
Stark, wenn Lese-Last viel höher als Schreib-Last (E-Commerce).
Event Sourcing
State ist nicht das, was in der DB steht — sondern die Folge aller Events. State = events.reduce(apply, initialState).
Vorteile: vollständige Historie, Replay möglich, Audit eingebaut.
Nachteil: Komplex, viele Events, Schema-Evolution kniffelig.
Outbox-Pattern
Problem: schreibt der Service in DB UND publiziert er Event — was, wenn DB-Commit klappt aber Publish fehlschlägt? → Inkonsistenz.
Lösung: Event in eine "outbox"-Tabelle in derselben DB-Transaktion schreiben. Separater Worker liest outbox + publiziert.
Zurück zu Technik