FACHWISSEN · TECHNIK & PROZESSETECHNICAL KNOWLEDGE · SYSTEMS & PROCESSES
Vernetzte Systeme: Warum identische Wiederholungsabstände eine Störung verstärken könnenConnected systems: Why identical retry intervals can amplify an outage
Ein Dienst antwortet kurzzeitig nicht. Viele angebundene Geräte warten jeweils eine Sekunde und versuchen es erneut. Was einzeln vernünftig wirkt, kann gemeinsam eine neue Lastspitze auslösen. Entscheidend ist nicht nur, ob wiederholt wird, sondern wann, wie oft und unter welchen Bedingungen.
Gleicher Takt bündelt die Last
Wenn viele Teilnehmer gleichzeitig ausfallen und denselben festen Abstand verwenden, bleiben ihre Versuche zeitlich gebündelt. Auch ein schrittweise wachsender Abstand kann diesen Gleichlauf erhalten. Der überlastete Dienst erhält dann wiederkehrende Spitzen statt einer gleichmäßiger verteilten Nachfrage.
Eine zufällige Streuung der Wartezeit wird als Jitter bezeichnet. Sie kann solche Gruppen entzerren. Die Streuung ist kein Ersatz für Kapazitätsplanung, sondern ein Baustein, um zeitlich gekoppelte Wiederholungen zu begrenzen.
Ein vereinfachtes Zahlenbeispiel
In einem fiktiven System versuchen 100 Geräte nach einem gemeinsamen Verbindungsabbruch erneut zuzugreifen. Bei exakt zwei Sekunden Wartezeit können viele Anfragen wieder gemeinsam eintreffen. Werden die Wartezeiten stattdessen innerhalb eines geeigneten Fensters verteilt, verteilen sich auch die erneuten Anfragen eher über dieses Fenster.
Das Beispiel beschreibt eine zeitliche Wirkung, keine garantierte Erfolgsquote. Netzausbreitung, Laufzeitumgebung und Zufallsverteilung beeinflussen das tatsächliche Ergebnis. Die Auslegung muss deshalb mit dem jeweiligen System geprüft werden.
Wiederholungen brauchen Grenzen
Eine maximale Versuchszahl oder ein Gesamtzeitbudget verhindert endloses Nachfragen. Dauerhafte fachliche Fehler sollten nicht wie vorübergehende Verbindungsprobleme behandelt werden. Auch mehrere Ebenen, die jeweils selbst wiederholen, können die Gesamtzahl der Anfragen stark erhöhen.
Bei schreibenden Vorgängen muss zusätzlich geklärt sein, ob ein erneuter Versuch eine doppelte Wirkung auslösen könnte. Zufällige Wartezeiten lösen dieses Problem nicht.
Störfälle im Verbund testen
Ein Einzeltest mit einem Gerät zeigt den Gleichlaufeffekt kaum. Aussagekräftiger ist ein kontrollierter Test mit mehreren Teilnehmern und einem gemeinsamen Auslöser. Beobachtet werden Anfrageverteilung, gesamte Versuchszahl und Zeit bis zur Erholung.
Damit wird aus einer scheinbar kleinen Client-Einstellung eine bewusst gestaltete Eigenschaft des Gesamtsystems.
A service briefly stops responding. Many connected devices each wait one second and try again. What looks reasonable in isolation can create another load spike when everybody does it together. The important questions are not only whether to retry, but when, how often and under which conditions.
Identical timing concentrates demand
When many clients fail together and use the same fixed delay, their attempts remain grouped in time. Even a progressively increasing delay can preserve this synchronisation. The struggling service then receives recurring peaks rather than more evenly distributed demand.
Random variation in the waiting time is known as jitter. It can spread these groups out. Jitter does not replace capacity planning; it is one way to limit tightly coupled retries.
A simplified numerical example
In a fictional system, 100 devices reconnect after a shared connection failure. With an exact two-second delay, many requests may arrive together again. If delays are spread across a suitable window, the renewed requests are more likely to be distributed across that window.
This example describes a timing effect, not a guaranteed success rate. Network conditions, execution environments and the random distribution affect the actual result. The design therefore needs testing in the relevant system.
Retries need boundaries
A maximum attempt count or an overall time budget prevents endless requests. Permanent business errors should not be treated like temporary connection failures. Several layers that each retry independently can also greatly increase the total number of requests.
For operations that change state, the design must additionally address whether another attempt could cause a duplicate effect. Random delays do not solve that problem.
Test failures with several clients
A single-device test reveals little about synchronised retries. A controlled test with multiple clients and a shared trigger is more informative. Observe the request distribution, total attempt count and time to recovery.
A seemingly minor client setting then becomes a deliberately designed property of the system as a whole.