Seminar NestJS – Intensivseminar Microservices und verteilte Architekturen

Verteilte Systeme entstehen nicht allein durch das Aufteilen einer Anwendung. Fachliche Grenzen, Nachrichtenverträge, Konsistenzmodelle, Fehlerverhalten und Beobachtbarkeit müssen gemeinsam entworfen werden.

Das Intensivformat verdichtet die Architektur-, GraphQL-, WebSocket- und Microservices-Seminare. Eine Plattform verbindet synchrone APIs, asynchrone Ereignisse, Echtzeitkanäle und föderierte Abfragen. Ausfälle, Duplikate und Verzögerungen gelten als normale Betriebszustände.

Inhaltsübersicht

• Lernziele
• Domänenschnitt und verteilte Verantwortlichkeiten
• CQRS, Events und zeitliche Konsistenz
• Messaging, RPC und Resilienz
• GraphQL, Federation und Echtzeitkanäle
• Verteilte Tests und Observability
• Durchgängiges Praxisprojekt: Verteilte Auftragsplattform
• Prüfpunkte und typische Fehler

Lernziele

• Fachdomänen und Bounded Contexts als Grundlage verteilter Verantwortlichkeiten schneiden.
• DDD, CQRS, Domain Events und Event Sourcing gezielt einsetzen.
• Synchrone sowie asynchrone Kommunikationsmodelle mit stabilen Verträgen gestalten.
• GraphQL Federation, Subscriptions und WebSockets sicher und skalierbar integrieren.
• Idempotenz, Outbox, Sagas, Timeouts, Wiederholungen und Circuit Breaker umsetzen.
• Logs, Metriken, Traces und Korrelationsdaten über mehrere Dienste verbinden.

Domänenschnitt und verteilte Verantwortlichkeiten

Jeder Dienst erhält eine eindeutige fachliche Verantwortung, eigene Datenhoheit und einen dokumentierten Vertrag zu abhängigen Kontexten.

1. Geschäftsereignisse, Regeln und Begriffe der Beispieldomäne erfassen.
2. Bounded Contexts, Upstream- und Downstream-Beziehungen festlegen.
3. Aggregate, Transaktionsgrenzen und Datenhoheit je Kontext definieren.
4. Synchrone und asynchrone Interaktionen nach Kopplung und Reaktionszeit bewerten.
5. Kontextgrenzen in NestJS-Module und eigenständig betreibbare Dienste überführen.
6. Verträge, Fehlerfälle und Verantwortlichkeiten in Architekturentscheidungen dokumentieren.

Entscheidungskriterien und Hinweise

• Datenbanken werden nicht serviceübergreifend als Integrationsschnittstelle geteilt.
• Dienstgrenzen entstehen aus Fachlichkeit und unabhängigen Änderungsgründen.

CQRS, Events und zeitliche Konsistenz

Commands, Queries und Domain Events strukturieren die Anwendungsfälle. Event Sourcing wird für einen ausgewählten Kontext eingesetzt; andere Dienste verwenden klassische Persistenz mit Outbox.

1. Commands mit eindeutiger Absicht, Korrelation und idempotenter Identität entwerfen.
2. Queries auf konkrete Leseanforderungen und getrennte Projektionen zuschneiden.
3. Domain Events als unveränderliche fachliche Tatsachen veröffentlichen.
4. Outbox und Inbox für atomare Veröffentlichung und Deduplikation einsetzen.
5. Event Streams, Versionierung, Projektionen und Rebuild implementieren.
6. Sagas mit Kompensation, Timeout und manueller Klärung modellieren.

Entscheidungskriterien und Hinweise

• Technische Zustellung und fachliche Wirkung werden getrennt betrachtet.
• Event Sourcing bleibt auf Kontexte mit begründetem Nutzen beschränkt.

Messaging, RPC und Resilienz

RPC, Commands und Events erhalten unterschiedliche Erwartungen an Antwort, Wiederholung, Reihenfolge und Fehlerbehandlung.

1. Kommunikationsmatrix für Latenz, Kopplung, Volumen, Reihenfolge und Ausfalltoleranz erstellen.
2. Synchrone RPC-Verbindung mit Timeout, Abbruch und Fehlerübersetzung implementieren.
3. Asynchrone Commands und Events mit stabiler Nachrichtenhülle veröffentlichen.
4. Retry mit Backoff, Jitter, Maximalversuchen und Dead-Letter-Behandlung konfigurieren.
5. Idempotente Consumer und Deduplikationsspeicher aufbauen.
6. Circuit Breaker, Bulkhead und Lastbegrenzung ergänzen.
7. Duplikat, Verzögerung, Reihenfolgefehler und Nichterreichbarkeit testen.

Entscheidungskriterien und Hinweise

• Retries sind begrenzt und nach Fehlerklasse gesteuert.
• Consumer bleiben bei mindestens-einmaliger Zustellung fachlich idempotent.

GraphQL, Federation und Echtzeitkanäle

Der verteilte Zugriff wird über einen föderierten Graphen und gezielte Echtzeitkanäle bereitgestellt. Teilgraphen folgen den Domänengrenzen.

1. Schema, Ownership, Entity-Schlüssel und Kompositionsregeln pro Teilgraph definieren.
2. Referenzauflösung ohne versteckte Kaskaden und N+1-Zugriffe implementieren.
3. Berechtigungen, Abfragekosten und partielle Fehler kontrollieren.
4. Subscriptions mit authentifiziertem Verbindungsaufbau und mandantenfähigen Topics bereitstellen.
5. WebSocket-Gateways für bidirektionale Interaktion, Räume und Präsenz ergänzen.
6. Mehrere Instanzen über gemeinsamen Broker oder Adapter synchronisieren.
7. Reconnect, verpasste Ereignisse, Backpressure und langsame Clients testen.

Entscheidungskriterien und Hinweise

• Echtzeitkanäle transportieren fachlich relevante Änderungen statt interner Tabellenereignisse.
• Federation darf zyklische Dienstabhängigkeiten nicht verdecken.

Verteilte Tests und Observability

Telemetrie wird so gestaltet, dass ein fachlicher Vorgang über HTTP, GraphQL, WebSocket und Messaging nachvollziehbar bleibt.

1. Korrelations-, Kausalitäts- und Nachrichten-IDs über alle Transportwege weitergeben.
2. Strukturierte Logs mit Dienst, Version, Kontext und fachlichem Ereignis erzeugen.
3. Metriken für Latenz, Durchsatz, Fehler, Retry, Queue-Lag und Consumer-Zustand definieren.
4. Traces über synchrone Aufrufe und asynchrone Nachrichten fortsetzen.
5. Liveness, Readiness und Abhängigkeitszustände je Dienst getrennt abbilden.
6. Contract-, Kompositions-, Komponenten- und End-to-End-Tests kombinieren.
7. Fehlerfälle durch kontrolliertes Abschalten, Verzögern und Duplizieren prüfen.

Entscheidungskriterien und Hinweise

• Telemetrie verbindet technische Symptome mit fachlicher Auswirkung.
• Mehrdienst-Tests bleiben reproduzierbar und isoliert.

Durchgängiges Praxisprojekt: Verteilte Auftragsplattform

Eine Auftragsplattform wird in Auftrag, Bestand, Abrechnung und Benachrichtigung geschnitten. Der Zugriff erfolgt über einen föderierten Graphen; Statusänderungen werden über Events, Subscriptions und einen WebSocket-Kanal verteilt.

Ein Bestellablauf enthält Reservierung, Zahlung, Kompensation und Benachrichtigung. Das Labor simuliert langsame Dienste, Duplikate, Broker-Unterbrechung und einen fehlerhaften Projektionshandler.

1. Bounded Contexts, Datenhoheit, Verträge und Kommunikationsmatrix festlegen.
2. Commands, Queries, Events und eine Event-Sourcing-Projektion implementieren.
3. Outbox, Messaging, idempotente Consumer und Saga für den Bestellablauf ergänzen.
4. Föderierte Teilgraphen mit Entity-Auflösung und Kompositionsprüfung aufbauen.
5. Authentifizierte Subscription und skalierbares WebSocket-Gateway bereitstellen.
6. Timeouts, Retries, Dead-Letter-Behandlung, Circuit Breaker und Lastbegrenzung konfigurieren.
7. Logs, Metriken und Traces zu einem vollständigen Ablauf korrelieren.
8. Ausfall-, Duplikat-, Verzögerungs- und Wiederanlauftests durchführen.

Prüfpunkte und typische Fehler

• Jeder Dienst besitzt eine fachliche Verantwortung und eigene Datenhoheit.
• Transportauswahl folgt Nachrichtenbedeutung und Fehleranforderungen.
• Consumer sind idempotent.
• Sagas besitzen Timeout-, Kompensations- und manuelle Klärungspfade.
• Federation und Echtzeitkanäle verdecken keine zyklischen Abhängigkeiten.
• Telemetrie erlaubt die Rekonstruktion eines Vorgangs über alle Schritte.