Annahmen über Verteilung
Verteilte Systeme kommunizieren über Netzwerke mit Verzögerung, Ausfall und begrenzten Ressourcen. Architektur muss diese Eigenschaften als normale Betriebsbedingungen berücksichtigen.
- IrrtumStille Annahme über das Netz.
- FolgeWas das für den Aufruf bedeutet.
- EntwurfsreaktionKonkrete Entscheidung im Ablauf.
Einordnung
Warum das wichtig ist
Wer Aufrufe über Dienstgrenzen wie lokale Methodenaufrufe behandelt, verlässt sich still auf Annahmen, die im Netz nicht gelten. Die acht Irrtümer nach L Peter Deutsch machen diese Annahmen prüfbar. Timeout, Retry und Breaker vertiefen eigene Bausteine.
Dieser Baustein übersetzt Netzwerkannahmen in Entwurfsfragen. Timeout, Retry und Observability vertiefen konkrete Schutz- und Diagnosemechanismen.
Auf einen Blick · Stille Annahmen über das Netz
Die acht Irrtümer im Zahlungsablauf
Die Shop-Anwendung fragt einen externen Zahlungsanbieter ab. Das Team prüft, was Verzögerung, Trennung und variable Antwortzeiten für den Ablauf bedeuten.
So liest du das Bild
- Irrtum Die erste Spalte, etwa „Das Netz ist zuverlässig“.
- Folge Die Spalte „Folge für den Aufruf“ und der Fall im Shop daneben.
- Entwurfsreaktion Die letzte Spalte, etwa „Kennung behalten, Status abfragen“ bei ausbleibender Antwort.
| Irrtum | Folge für den Aufruf | Fall im Shop | Entwurfsreaktion |
|---|---|---|---|
| Das Netz ist zuverlässig | Antwort kann ausbleiben | Zahlung P-731 bleibt ohne Antwort | Kennung behalten, Status abfragen |
| Latenz ist null | Antwortzeit schwankt und kann lang sein | Zeitbudget 1.000 ms; Antwort kam erst bei 1.500 ms | Zeitbudget festlegen, Klärung anzeigen |
| Bandbreite ist unendlich | Große Antworten stauen sich | Ein Aufruf liefert mehr Bestelldaten, als die Seite braucht | Nur benötigte Felder abrufen |
| Das Netz ist sicher | Fremde können mitlesen oder eingreifen | Zahlungsdaten laufen zum externen Anbieter | Verschlüsseln, Aufrufer prüfen |
| Die Topologie ändert sich nicht | Adressen und Instanzen wechseln | Der Anbieter zieht auf eine andere Adresse um | Namen auflösen, Adressen nicht festschreiben |
| Es gibt genau einen Administrator | Verantwortung liegt bei mehreren Parteien | Shop-Team und Zahlungsanbieter ändern unabhängig voneinander | Verträge und Absprachen versionieren |
| Transportkosten sind null | Jeder Aufruf kostet Zeit und Ressourcen | Viele kleine Zahlungsabfragen je Bestellung addieren sich | Aufrufe bündeln, Gesamtpfad messen |
| Das Netz ist homogen | Gegenstellen verhalten sich verschieden | Der Anbieter nutzt andere Formate und Fehlercodes als der Shop | Verträge prüfen, Fehler übersetzen |
Nutzen & Grenzen
Hilft, wenn
- Netzwerkkommunikation ergänzt variable Latenz und Teilfehler zu lokalen Funktionsabhängigkeiten.
- Verkettete Remote-Aufrufe können Verzögerungen und Ausfälle über den Gesamtpfad weitergeben.
- Daten- und Identitätsübergänge über Prozessgrenzen brauchen Serialisierung, Zugriffsschutz und Versionsregeln im Vertrag.
Grenzen
- Die acht Irrtümer sind Denkanstöße, keine vollständige Checkliste; prüfe jeden Aufruf über eine Dienstgrenze einzeln.
- Schutzmechanismen kosten selbst Zeit und Betrieb; Timeout und Retry brauchen abgestimmte Werte, sonst verschärfen sie die Lage.
- Ob ein Irrtum im Betrieb wirkt, zeigen erst Messungen; Observability macht Latenz und Abbrüche sichtbar.
In der Praxis
- Zähle Netzwerk-Roundtrips im vollständigen Ablauf und bündele fachlich zusammengehörige Daten in gröbere Operationen. Miss Gesamtlatenz statt nur Einzelaufrufe.
- Definiere Fehlersemantik, Identität und Zeitbudget für jede Remote-Grenze. Ein abgebrochener Aufruf braucht ein unterscheidbares Ergebnis für den Aufrufer.
- Variiere Verzögerung, Verlust und Zielwechsel in Prüfungen. Timeout begrenzt Wartezeit; Backpressure schützt bei Rückstau.
Ausführliche Erklärung lesen
Netzwerkaufrufe haben variable Latenz, können ausfallen und übertragen versionierte Daten über eine Sicherheitsgrenze. Sie besitzen andere Fehler- und Kostenmerkmale als Aufrufe innerhalb desselben Prozesses.
Viele kleine Roundtrips vervielfachen Wartezeiten und mögliche Fehlerstellen. Gröbere fachliche Operationen, klare Fehlersemantik und messbare Zeitbudgets helfen, diese Eigenschaften in der Architektur zu berücksichtigen.
Timeout begrenzt Wartezeit, Backpressure begrenzt angebotene Last; gemeinsam machen sie aus Netzwerkannahmen konkrete Zeit- und Kapazitätsbudgets.
Die acht Irrtümer gehen auf L Peter Deutsch und Kollegen bei Sun Microsystems zurück.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Entwurfsreaktion gehört zum Irrtum „Das Netz ist zuverlässig“?
Lösung mit Begründung ansehen
Die Kennung behalten und den Status abfragen, denn die Antwort zur Zahlung P-731 kann ausbleiben.
AnwendenAuf eine neue Lage übertragen
Der Zahlungsanbieter zieht auf eine neue Adresse um, und der Shop erreicht ihn nicht mehr. Welcher Irrtum steckt dahinter, und was hilft?
Lösung mit Begründung ansehen
„Die Topologie ändert sich nicht“. Der Shop löst den Anbieter über einen Namen auf, statt die Adresse festzuschreiben.
BewertenEine Alternative abwägen
Das Team setzt das Zeitbudget für Zahlungsaufrufe sehr großzügig, damit Latenzschwankungen nie auffallen. Was spricht dafür, was dagegen?
Lösung mit Begründung ansehen
Dafür: Weniger Aufrufe brechen vorzeitig ab. Dagegen: Der Aufrufer wartet lange, und der Shop kann die ausstehende Klärung erst spät anzeigen. Ein festes Zeitbudget mit Klärungszustand bleibt steuerbarer.
Vertiefen
Diese Bausteine führen die Gedanken dieser Seite weiter.
Quellen
- Martin Fowler – First Law of Distributed Object Design (öffnet in neuem Tab)Erklärt Folgen von Netzwerklatenz und entfernten Aufrufen für den Schnitt von Diensten.
- AWS – Challenges with distributed systems (öffnet in neuem Tab)Zeigt praktische Grenzen von Annahmen über Netzwerk, Zeit und Fehlererkennung.
- AWS – Timeouts, retries, and backoff with jitter (öffnet in neuem Tab)Erklärt Timeouts, begrenzte Wiederholungen und Jitter anhand verteilter Ausfälle.