# 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.

Track: [Distributed Systems & API Reliability](https://physar.tech/learn/distributed-systems)  
Kanonische Fassung: https://physar.tech/learn/distributed-systems/failure-aware-contracts  
Stand: 2026-07-26

## In verteilten Systemen ist Unklarheit ein normaler Zustand

### 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.

_[Abbildung: Ein belastbarer Dienstvertrag verbindet Request, Wirkung, Beobachtung und Rückweg, statt eine erfolgreiche Antwort mit einer erfolgreichen Wirkung gleichzusetzen.]_

> **Merksatz:** Kommunikationsunsicherheit darf nicht unbemerkt zu fachlicher Unsicherheit werden.

### Idempotenz und Zustandsübergänge

|  |  |
| --- | --- |
| Idempotenter Schlüssel | Mehrfacher gleicher Auftrag führt zu einer nachvollziehbaren statt doppelten fachlichen Wirkung. |
| Outbox oder Queue | Entkoppelt lokale Zustandsänderung und spätere Zustellung mit beobachtbarem Status. |
| Kompensation | Behandelt einen bereits eingetretenen Effekt; sie ist kein unsichtbares Zurückspulen. |

> **Grenze:** Genau-einmal-Verarbeitung ist selten eine Transporteigenschaft. Entscheidend ist die fachliche Deduplizierung und Beobachtbarkeit der Wirkung.

### Last kontrollieren statt weiterreichen

Anfrage begrenzen → Timeout und Budget setzen → **Wirkung eindeutig kennzeichnen** → Backpressure oder Queue nutzen → 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

## Quellen

- Google SRE Book: Handling Overload — https://sre.google/sre-book/handling-overload/
- Google SRE Book: Addressing Cascading Failures — https://sre.google/sre-book/addressing-cascading-failures/