Resilienz und
Fehlerbehandlung

Resilienz ist die Fähigkeit eines Systems, unter Störungen einen kontrollierten Dienst zu erbringen und danach in einen bekannten Zustand zurückzukehren. Ein resilientes System erkennt Grenzen, verliert angenommene Arbeit nicht unbemerkt und lässt sich diagnostizieren. Es verspricht nicht, dass jedes Ziel immer erreichbar ist.

Fehler müssen zuerst klassifiziert werden. Ein vorübergehender technischer Fehler kann ein Timeout, DNS-Problem oder HTTP 503 sein. Ein späterer Versuch kann erfolgreich sein. Ein dauerhafter technischer Fehler ist beispielsweise eine falsche URL oder ungültige Konfiguration. Ein fachlicher Fehler liegt vor, wenn eine SKU unbekannt, ein Kunde gesperrt oder eine DICOM-Studie unvollständig ist. Wiederholen ohne Zustandsänderung behebt solche Fehler normalerweise nicht.

Hinzu kommen Überlastung, Teilfehler und ungewisse Resultate. Nach einem Timeout weiss der Client möglicherweise nicht, ob der Server vor dem Verbindungsabbruch geschrieben hat. In verteilten Systemen ist diese Unsicherheit normal. Die Architektur muss deshalb nicht nur Fehler anzeigen, sondern Doppelwirkungen und unkontrollierte Wiederholungen verhindern.

Ein Retry ist sinnvoll, wenn der Fehler wahrscheinlich vorübergehend ist und die Operation sicher wiederholt werden kann. Sofortige, unbegrenzte Wiederholungen verschlimmern einen Ausfall: Tausende Clients belasten einen bereits gestörten Dienst zusätzlich. Exponentieller Backoff vergrössert den Abstand zwischen Versuchen, zum Beispiel eine, zwei, vier und acht Sekunden. Jitter fügt eine kleine Zufallsabweichung hinzu, damit nicht alle Instanzen gleichzeitig erneut senden.

Jede Retry-Policy braucht eine Obergrenze, eine maximale Gesamtdauer und eine Liste geeigneter Fehler. Ein 503 oder Netzwerkabbruch kann wiederholt werden; ein 401 verlangt meist korrigierte Zugangsdaten; ein 422 verlangt veränderte Fachdaten. Nach Ausschöpfen der Versuche braucht es einen sichtbaren nächsten Zustand statt endloser Verarbeitung.

Ein Circuit Breaker stoppt Aufrufe an ein erkennbar gestörtes Ziel für eine begrenzte Zeit. Dadurch werden Ressourcen geschützt und schnelle, kontrollierte Fehler möglich. Er ersetzt weder Monitoring noch Retry, sondern verhindert aussichtslose Dauerlast.

Viele Nachrichtensysteme arbeiten mit At-least-once Delivery: Eine Nachricht wird mindestens einmal, möglicherweise mehrfach zugestellt. Wenn ein Worker die Fachaktion erfolgreich ausführt, aber vor der Bestätigung abstürzt, liefert die Queue dieselbe Nachricht erneut. Das schützt vor Verlust, erzeugt jedoch Duplikatrisiko.

Idempotenz verhindert den zweiten fachlichen Effekt. Im Handel kann eine eindeutige externe Bestellreferenz nur einen ERP-Auftrag erlauben. Im Spital kann die Kombination aus StudyInstanceUID, Ziel und Verarbeitungstyp einen Transfer eindeutig machen. Eine Event-ID kann zusätzlich die konkrete Nachricht deduplizieren. Die Prüfung muss atomar mit der Verarbeitung koordiniert werden; ein blosses „zuerst nachsehen, dann schreiben“ besitzt bei parallelen Workern ein Rennen.

„Exactly once“ ist oft nur innerhalb eines begrenzten technischen Systems garantiert. Über Queue, Datenbank und Fremd-API hinweg ist ein genau einmal wirkender fachlicher Effekt durch Idempotenz realistischer als ein globales Transportversprechen.

Eine Dead-Letter Queue (DLQ) nimmt Nachrichten auf, die nach einer definierten Behandlung nicht verarbeitet werden konnten. Sie ist kein Papierkorb, sondern eine Quarantäne mit Originalnachricht, Fehlerklasse, Zeitstempel, Versuchszahl und Correlation-ID. Ohne Alarm, Besitzer und Bearbeitungsfrist wird sie zum versteckten Friedhof.

Beim Replay wird ein Fall nach Analyse erneut verarbeitet. Die ursprüngliche Nachricht sollte für die Nachvollziehbarkeit unverändert bleiben. Korrigiert werden beispielsweise Stammdaten, Konfiguration oder eine explizite neue Ersatznachricht. Vor dem Replay muss geklärt sein, ob bereits ein Teil der Fachwirkung eingetreten ist. Idempotenz bleibt deshalb auch beim manuellen Wiederanlauf wichtig.

Logs beantworten einzelne Ereignisse, Metriken zeigen Mengen und Trends, Traces verbinden Stationen eines Ablaufs. Eine Correlation-ID begleitet Request, Event, Retry und Zielobjekt. Wichtige Metriken sind Queue-Tiefe, Alter der ältesten Nachricht, Fehlerrate, Retry-Zahl, DLQ-Zuwachs und Verarbeitungsdauer. Ein Alarm sollte eine Handlung auslösen, nicht bloss Geräusch erzeugen.

Im Spitalbeispiel dürfen Logs keine echten Patientennamen oder unnötigen DICOM-Tags enthalten. Im Handel gehören Passwörter, Tokens und Zahlungsdaten nicht ins Log. Beobachtbarkeit und Datenschutz müssen gemeinsam entworfen werden.

1. Klassifiziere Fehler vor der Wahl einer Reaktion: temporär, dauerhaft technisch, fachlich oder Überlastung.
2. Begrenze Retries nach Anzahl und Dauer; verwende Backoff und Jitter.
3. Mache jede wiederholbare Schreiboperation fachlich idempotent.
4. Definiere DLQ-Besitzer, Alarm, Diagnoseinformationen, Frist und Replay-Verfahren.
5. Bewahre Originalnachrichten und protokolliere Korrekturen nachvollziehbar.
6. Überwache Queue-Tiefe, Nachrichtenalter, Fehler, Retries und DLQ.
7. Teste Ausfall, Wiederanlauf und Doppelzustellung – nicht nur den Happy Path.