Microservices-Design Schulung: Entwurfsmuster bis Saga und Outbox

Muster als Arbeitswerkzeug

• Microservices-Probleme mit Mustern lösen: Problem, Kontext, Lösung, Kosten und Folgemuster
• Terminologie der Microservices: Service, Instanz, Bounded Context, Vertrag, Ereignis
• Microservices und Cloud Native: welche Muster Kubernetes und Managed Services bereits mitbringen
• Anti-Muster erkennen: verteilter Monolith, geschwätzige Services, geteilte Fachbibliothek
• Die Mustersprache von microservices.io als Landkarte: Musterfamilien und ihre Abhängigkeiten

Zerlegungsmuster

• Dekomposition eines Systems: Kohäsion, Änderungsrate und Datenhoheit als Schnittkriterien
• Domänenbasierte Microservices: Subdomänen und Bounded Contexts als Servicegrenze
• Geschäftsprozessbasierte Microservices: Service je Prozessschritt und die Kopplung, die dabei entsteht
• Atomare transaktionsbasierte Microservices: was gemeinsam konsistent sein muss, bleibt in einem Service
• Strangler-Muster: Fassade und schrittweise Umleitung – Migration im Detail im Monolith-Seminar
• Sidecar-Muster: Querschnittsaufgaben wie TLS, Proxy oder Log-Versand im Begleitcontainer
• Ambassador und Adapter als Varianten des Sidecars für ausgehende Aufrufe und Formatanpassung
• Service Mesh als flächendeckender Sidecar mit Envoy – und Istio Ambient ganz ohne Sidecar

Integrations- und Edge-Muster

• Gateway-Muster: Routing, Authentifizierung und Ratenbegrenzung an einem Einstiegspunkt
• Gateway-Routing, Gateway-Aggregation und Gateway-Offloading als Teilmuster unterscheiden
• Prozess-Aggregator-Muster: ein Service ruft mehrere Dienste auf und fasst die Ergebnisse zusammen
• API Composition für Lesezugriffe: Teilausfälle in der Antwort kennzeichnen statt alles abzubrechen
• Edge-Muster: Backend for Frontend je Client-Typ und wer es verantwortet
• Anticorruption Layer: Fremd- und Altsysteme anbinden, ohne deren Modell zu übernehmen

Datenmuster

• Datenbank für einzelne Dienste: private Tabellen, eigenes Schema oder eigener Datenbankserver
• Gemeinsam genutzte Service-Datenbank: wann sie vertretbar ist und welche Kopplung sie erzeugt
• Command Query Responsibility Segregation (CQRS): Schreibmodell, Lesemodell und Projektion
• Event Sourcing als optionale Ergänzung zu CQRS: Ereignisspeicher, Snapshots, Schemaänderungen
• Asynchrone Ereignisverarbeitung: Benachrichtigung, Event-Carried State Transfer und Domain Events
• Idempotente Consumer: Deduplizierung über Nachrichten-IDs bei at-least-once-Zustellung
• Reihenfolge je Fachschlüssel über Partitionen in Kafka sicherstellen

Konsistenzmuster: Saga und Transactional Outbox

• Saga per Choreografie: jeder Service reagiert auf das Ereignis des vorherigen Schritts
• Saga per Orchestrierung: Orchestrator als Zustandsautomat, umgesetzt etwa mit Temporal oder Camunda
• Kompensationen entwerfen: Storno statt Rollback, kompensierbare, pivotale und wiederholbare Schritte
• Fehlende Isolation in Sagas: Semantic Lock, kommutative Änderungen und erneutes Lesen
• Transactional Outbox: Zustandsänderung und Ereignis in derselben lokalen Transaktion speichern
• Outbox auslesen per Polling Publisher oder Transaction Log Tailing mit Debezium
• Inbox-Muster auf Empfängerseite gegen doppelte Verarbeitung nach Wiederholungen

Resilienzmuster

• Timeouts als Grundlage: jede ausgehende Verbindung und jeder Aufruf mit Obergrenze
• Retry mit exponentiellem Backoff und Jitter – nur für idempotente Operationen
• Retry-Stürme vermeiden: Wiederholung nur auf einer Ebene der Aufrufkette, Retry-Budget
• Circuit Breaker: Zustände geschlossen, offen und halb offen, Fehlerrate und Wartezeit einstellen
• Bulkhead: getrennte Thread- oder Verbindungs-Pools je Abhängigkeit gegen Ressourcenerschöpfung
• Fallbacks und Graceful Degradation: Cache-Wert, Standardantwort oder abgeschaltete Teilfunktion
• Rate Limiting und Load Shedding schützen den eigenen Service vor Überlast
• Umsetzung mit Resilience4j in Java, Polly bzw. Microsoft.Extensions.Http.Resilience in .NET oder als Richtlinie im Service Mesh

Betriebsmuster

• Protokoll-Aggregationsmuster: strukturierte Logs zentral sammeln und per Korrelations-ID verknüpfen
• Metriken-Aggregationsmuster: RED- und USE-Methode, Abfrage im Prometheus-Format
• Tracing-Muster: Trace-Kontext nach W3C mit OpenTelemetry über Services und Broker weiterreichen
• Health Check API: Liveness-, Readiness- und Startup-Probes richtig trennen
• Externe Konfiguration: Umgebungsvariablen, ConfigMaps und Secrets getrennt vom Build-Artefakt
• Service-Entdeckung clientseitig über eine Registry oder serverseitig per DNS und Kubernetes-Service
• Kontinuierliche Auslieferung je Service: eigene Pipeline, Blue-Green- und Canary-Deployments
• Unabhängige Releases absichern mit verbrauchergetriebenen Vertragstests
• Dokumentation: OpenAPI und AsyncAPI je Service, Servicekatalog etwa mit Backstage
• Musterentscheidungen samt verworfener Alternativen als Architecture Decision Record festhalten

Muster auswählen und kombinieren

• Folgemuster planen: Datenbank je Service zieht Saga, API Composition oder CQRS nach sich
• Kosten je Muster vergleichen: zusätzliche Infrastruktur, Betriebsaufwand, Lernkurve im Team
• Musterkombinationen an Fallbeispielen bewerten: was zusammenpasst und was sich widerspricht

Microservices-Muster mit Claude Code umsetzen

• Freigegebener Microservices-Musterkatalog des Teams als Projektkontext begrenzt, was der Agent vorschlägt
• Agent implementiert Outbox-Tabelle und Relay; ein Test bricht den Prozess zwischen Commit und Versand ab
• Resilience4j-Konfiguration vom Agenten, Abnahme per Chaos-Test mit Toxiproxy und verlangsamtem Nachbardienst
• Vor dem Code listet der Agent je Saga-Schritt Aktion, Kompensation und Wiederholbarkeit als Tabelle
• Agent durchsucht den Code nach Aufrufen ohne Timeout und Retries auf nicht idempotenten Endpunkten

Praxisprojekt: Kartenverkauf für einen Konzertveranstalter

• Platzreservierung, Zahlung und Ticketversand als orchestrierte Saga mit Kompensation
• Saalplan mit freien Plätzen als CQRS-Lesemodell, Ereignisse über eine Transactional Outbox
• Zahlungsdienst künstlich verlangsamen und Circuit Breaker, Bulkhead und Fallback messen
• Ablauf per Tracing nachvollziehen und die gewählten Muster als ADRs begründen

Lernziele

• Sie beschreiben für jedes behandelte Muster Problem, Lösung, Kosten und Folgemuster
• Sie wählen Zerlegungs-, Integrations- und Datenmuster für ein gegebenes System begründet aus
• Sie entwerfen eine Saga mit Kompensationen und sichern den Ereignisversand mit einer Transactional Outbox ab
• Sie konfigurieren Timeout, Retry, Circuit Breaker und Bulkhead und weisen ihre Wirkung im Test nach
• Sie legen Betriebsmuster für Logs, Metriken, Tracing, Konfiguration und Service-Entdeckung fest

Zielgruppe

• Softwarearchitekt:innen, die Muster für verteilte Systeme gezielt auswählen und bewerten
• Erfahrene Entwickler:innen, die Microservices umsetzen und Resilienz- und Konsistenzmuster im Code verankern
• Tech Leads, die Architekturentscheidungen in Reviews nachvollziehbar machen wollen