Seminar NestJS – Microservices, Messaging und Resilienz

NestJS abstrahiert verschiedene Transportmechanismen, die fachlichen und betrieblichen Konsequenzen bleiben jedoch bestehen. Nachrichten können doppelt, verspätet, in anderer Reihenfolge oder gar nicht verarbeitet werden; abhängige Dienste können langsam oder nicht verfügbar sein.

Der Kurs konzentriert sich deshalb auf belastbare Kommunikations- und Fehlermodelle. Transporter werden verglichen, aber Verträge, Zustellsemantik, Datenkonsistenz, Wiederanlauf und Beobachtbarkeit bestimmen die Architekturentscheidung.

Inhaltsübersicht

• Lernziele
• Servicegrenzen und Kommunikationsmatrix
• NestJS-Transporter und Nachrichtenverträge
• Zuverlässigkeit und verteilte Konsistenz
• Resilienz und Lastkontrolle
• Tests und verteilte Observability
• Praxisprojekt: Verteilte Bestellabwicklung
• Prüfpunkte und typische Fehler

Lernziele

• Dienstgrenzen, Datenhoheit und Kommunikationsbedarf fachlich begründet festlegen.
• RPC, Commands und Events hinsichtlich Kopplung, Antwortverhalten und Fehlersemantik unterscheiden.
• NestJS-Transporter und externe Broker über stabile Nachrichtenverträge integrieren.
• Idempotenz, Deduplikation, Outbox, Inbox und Sagas für verlässliche Abläufe umsetzen.
• Timeouts, Retries, Circuit Breaker, Bulkheads und Backpressure konfigurieren.
• Contract-, Komponenten- und End-to-End-Tests sowie verteilte Telemetrie aufbauen.

Servicegrenzen und Kommunikationsmatrix

Microservices werden aus fachlichen Verantwortlichkeiten und unabhängigen Änderungsgründen abgeleitet. Eine Kommunikationsmatrix verhindert, dass jedes Problem reflexartig mit einem Broker oder synchronem RPC gelöst wird.

1. Fachliche Kontexte, Datenhoheit und zentrale Invarianten erfassen.
2. Interaktionen nach Richtung, Latenz, Volumen, Antwortbedarf und Ausfalltoleranz klassifizieren.
3. Synchrone und asynchrone Kandidaten mit ihren Kopplungsfolgen vergleichen.
4. Nachrichtenverantwortung, Schema-Ownership und Versionspolitik festlegen.
5. Fehler- und Wiederanlaufverhalten je Interaktion dokumentieren.
6. Nur begründete Kontexte als eigenständig betreibbare Dienste schneiden.

Entscheidungskriterien und Hinweise

• Technische Deploymenteinheiten folgen fachlichen Grenzen und nicht Tabellenzuschnitten.
• Gemeinsam genutzte Datenbanken werden nicht als bequeme Integrationsschnittstelle eingesetzt.

NestJS-Transporter und Nachrichtenverträge

Transportmechanismen werden anhand desselben Geschäftsablaufs verglichen. Neben Durchsatz und Latenz zählen Routing, Reihenfolge, Zustellung, Antwortmodell und Betriebsaufwand.

1. Synchronen Aufruf mit explizitem Timeout, Deadline und Fehlervertrag implementieren.
2. Asynchrone Commands, Events und konkurrierende Consumer semantisch unterscheiden.
3. Nachrichtenhülle mit ID, Typ, Version, Zeit, Korrelation und Mandant standardisieren.
4. Routing, Partitionierung, Reihenfolge und Consumer-Gruppen bewusst konfigurieren.
5. Additive Schemaänderungen bevorzugen und Consumer-Kompatibilität prüfen.
6. Unbekannte Felder tolerant behandeln, entfernte Semantik aber nicht verdecken.
7. Contract-Prüfungen und repräsentative Beispielnachrichten versionieren.

Entscheidungskriterien und Hinweise

• Transportabstraktion hebt Broker- und Protokollsemantik nicht auf.
• Nachrichtenverträge werden unabhängig von internen Klassen und Datenbankmodellen gestaltet.

Zuverlässigkeit und verteilte Konsistenz

Mindestens-einmal-Zustellung macht Duplikate zu einem normalen Zustand. Die Anwendung muss fachliche Wirkungen deduplizieren und lokale Datenänderung mit Nachrichtenveröffentlichung koordinieren.

1. Idempotenzschlüssel und fachliche Eindeutigkeit pro Operation definieren.
2. Consumer mit Inbox- oder Deduplikationsspeicher absichern.
3. Outbox im selben Commit wie die fachliche Zustandsänderung schreiben.
4. Publisher für Wiederholung, Reihenfolge und Fehlerzustände implementieren.
5. Saga mit Schritten, Kompensation, Timeout und manueller Klärung modellieren.
6. Dead-Letter-Nachrichten klassifizieren und kontrolliert erneut einspielen.
7. Datenabgleich und Reparaturverfahren für langfristige Inkonsistenzen definieren.

Entscheidungskriterien und Hinweise

• Genau-einmalige fachliche Wirkung entsteht durch Idempotenz, nicht durch eine bloße Brokerbezeichnung.
• Kompensation ist eine neue fachliche Operation und kein technisches Zurückrollen einer verteilten Transaktion.

Resilienz und Lastkontrolle

Retries sind nur hilfreich, wenn Fehler vorübergehend und Operationen wiederholbar sind. Ohne Grenzen verschärfen sie Lastspitzen und verlängern Ausfälle.

1. Timeouts aus fachlicher Reaktionszeit und beobachteter Latenz ableiten.
2. Retry mit Exponential Backoff, Jitter, Maximaldauer und Fehlerklassifikation konfigurieren.
3. Circuit Breaker nach abhängiger Funktion und nicht global pro Dienst einsetzen.
4. Bulkheads, Concurrency-Limits und Queue-Grenzen zur Isolation verwenden.
5. Backpressure und Ablehnung statt unkontrolliertem Speicherwachstum vorsehen.
6. Load Shedding und Prioritäten für kritische sowie optionale Arbeit definieren.
7. Wiederanlauf nach Broker- oder Dienstunterbrechung mit realistischen Datenmengen testen.

Entscheidungskriterien und Hinweise

• Retry, Timeout und Circuit Breaker werden gemeinsam dimensioniert.
• Lastgrenzen werden sichtbar abgelehnt und nicht durch unendliche Warteschlangen verdeckt.

Tests und verteilte Observability

Die Testarchitektur kombiniert schnelle Handler-Tests mit realen Broker-, Datenbank- und Mehrdienst-Szenarien. Telemetrie korreliert einen fachlichen Vorgang über alle Transportwege.

1. Handler und idempotente Geschäftslogik mit Unit-Tests absichern.
2. Contract-Tests für Nachrichtenformate und semantische Beispiele aufbauen.
3. Komponententests mit realem Transporter, Broker und Datenbank ausführen.
4. End-to-End-Ablauf über mehrere Dienste und eine Saga prüfen.
5. Duplikate, Verzögerungen, falsche Reihenfolge und Dead-Letter-Fälle injizieren.
6. Korrelations- und Nachrichten-IDs in Logs, Metriken und Traces weitergeben.
7. Metriken für Latenz, Fehler, Retry, Queue-Lag und Nachrichtenalter definieren.

Entscheidungskriterien und Hinweise

• Ein grüner Publisher-Test belegt nicht die erfolgreiche fachliche Verarbeitung.
• Fehlerdiagnose verbindet Nachricht, Consumer, Datenzustand und fachlichen Vorgang.

Praxisprojekt: Verteilte Bestellabwicklung

Auftrag, Bestand, Zahlung und Benachrichtigung werden als getrennte Dienste umgesetzt. Ein synchroner Verfügbarkeitscheck wird mit einem asynchronen Reservierungs- und Zahlungsablauf verglichen.

Das Labor simuliert Duplikate, Broker-Ausfall, langsame Zahlung, Poison Message und konkurrierende Bestellungen. Der vollständige Ablauf muss nachvollziehbar, idempotent und wiederanlauffähig bleiben.

1. Servicegrenzen, Datenhoheit und Kommunikationsmatrix dokumentieren.
2. RPC- und Event-Verträge mit Version, Korrelation und Fehlersemantik definieren.
3. NestJS-Microservices und Broker-Anbindung implementieren.
4. Outbox, idempotente Consumer und Deduplikationsspeicher ergänzen.
5. Saga für Reservierung, Zahlung und Kompensation aufbauen.
6. Timeouts, Retries, Circuit Breaker und Lastgrenzen konfigurieren.
7. Contract-, Komponenten- und Mehrdienst-Tests ausführen.
8. Logs, Metriken und Traces für einen vollständigen Auftrag korrelieren.

Prüfpunkte und typische Fehler

• Servicegrenzen werden nicht nach Tabellen oder vorhandenen Teams ohne fachliche Prüfung gewählt.
• RPC, Commands und Events besitzen unterschiedliche, dokumentierte Semantik.
• Mindestens-einmalige Zustellung wird nicht als genau-einmalige Verarbeitung interpretiert.
• Retries sind begrenzt, klassifiziert und erzeugen keine Retry-Stürme.
• Dead-Letter-Nachrichten besitzen einen Analyse- und Wiedereinspielprozess.
• Observability zeigt fachlichen Zustand, Transportzustand und Fehlerursache gemeinsam.