physar / Distributed Systems & API Reliability / Verträge unter Teilausfall

Verträge unter Teilausfall

APIs und asynchrone Abläufe so gestalten, dass Timeouts, Retries und unklare Ergebnisse nicht zu doppelter oder still fehlerhafter Wirkung führen.

In verteilten Systemen ist Unklarheit ein normaler Zustand

Einführung · 4 Abschnitte · ~8 Min Lesezeit · Stand

Ein Timeout sagt nicht, was passiert ist

Wenn ein Client keine Antwort erhält, kann der Request nie angekommen, unterwegs verloren, erfolgreich verarbeitet oder nach der Wirkung abgebrochen sein. Ein Retry ist deshalb keine neutrale Netzwerktechnik, sondern eine fachliche Entscheidung über mögliche Doppelwirkung.

EIN IDENTIFIZIERTES ARTEFAKT DURCHLÄUFT KONTROLLIERTE GATESÄnderungbauen + prüfenArtefaktbegrenzt ausrollenWirkung prüfenSchlechtes Signal → bekannten Stand halten oder zurückrollen.
Ein belastbarer Dienstvertrag verbindet Request, Wirkung, Beobachtung und Rückweg, statt eine erfolgreiche Antwort mit einer erfolgreichen Wirkung gleichzusetzen.

Idempotenz und Zustandsübergänge

Idempotenter SchlüsselMehrfacher gleicher Auftrag führt zu einer nachvollziehbaren statt doppelten fachlichen Wirkung.
Outbox oder QueueEntkoppelt lokale Zustandsänderung und spätere Zustellung mit beobachtbarem Status.
KompensationBehandelt einen bereits eingetretenen Effekt; sie ist kein unsichtbares Zurückspulen.

Last kontrollieren statt weiterreichen

  1. Anfrage begrenzen
  2. Timeout und Budget setzen
  3. Wirkung eindeutig kennzeichnen
  4. Backpressure oder Queue nutzen
  5. Ergebnis beobachten und erklären

Circuit Breaker, Limits und Backpressure schützen einen Dienst nur, wenn Aufrufer einen definierten Degradations- oder Retry-Pfad erhalten.

Gleich im Check

  • Ein Timeout von einem sicher fehlgeschlagenen Auftrag unterscheiden
  • Idempotenz an der fachlichen Wirkung statt am HTTP-Status verorten
  • Lastbegrenzung mit einem erklärbaren Fallback verbinden

Gelesen ist nicht geprüft: Im Modul entscheidest du die Fälle selbst und siehst danach, wo dein Urteil trägt.

0 Checks starten →

Modul-Aufbau

EINFÜHRUNGIn verteilten Systemen ist Unklarheit ein normaler Zustand~8 Min

Quellen

  1. 01Google SRE Book: Handling Overload
  2. 02Google SRE Book: Addressing Cascading Failures

Verfasst von Julian Zentgraf