Thundering Herd Problem: was ist das und warum bricht es die Produktion

Thundering herd problem - ist eine Situation in der Softwareentwicklung, wenn viele Prozesse oder Anfragen gleichzeitig auf dieselbe Ressource zugreifen. Jeder von ihnen handelt logisch und korrekt, aber zusammen erzeugen sie einen plötzlichen Anstieg der Last, den das System nicht bewältigen kann.

Der Name ist metaphorisch: Stellen Sie sich eine Herde von Tieren vor, die gleichzeitig aufbricht. Einzelne Tiere sind kein Problem, aber zusammen können sie alles auf ihrem Weg niederreißen.

In der Praxis sieht das oft so aus: Sie haben einen Cache mit TTL. Der Schlüssel läuft ab, und in diesem Moment kommen viele Anfragen. Jede von ihnen sieht, dass der Cache leer ist, und beschließt, selbst zur Datenbank oder zu einem externen Dienst zu gehen. Infolgedessen erhalten Sie anstelle einer kontrollierten Anfrage Hunderte oder Tausende. Die Datenbank wird überlastet, die Latenz steigt, es treten Timeouts auf und manchmal sogar ein vollständiger Ausfall des Dienstes. Der Cache, der das System schützen sollte, verwandelt sich tatsächlich in einen Auslöser für eine Katastrophe.

Dieses Problem ist besonders tückisch, da es nicht in ruhigen Bedingungen auftritt, sondern genau in den schlimmsten Momenten: während des Spitzenverkehrs, nach dem Neustart von Diensten, bei Deployments oder wenn eine externe Abhängigkeit langsamer zu antworten beginnt. Lokal oder in der Staging-Umgebung ist es fast unmöglich, es zu reproduzieren, weshalb es in der Produktion wie ein "zufälliger" Vorfall ohne offensichtlichen Grund aussieht.

Gegen thundering herd kann man unterschiedlich vorgehen, aber die Idee ist immer die gleiche: Das System sollte sich nicht zu synchron verhalten. Oft reicht es aus, nur einem Prozess zu erlauben, den Cache zu aktualisieren, während alle anderen entweder warten oder den vorherigen Wert lesen. In anderen Fällen ist es besser, vorübergehend etwas veraltete Daten bereitzustellen, als eine Lawine von Anfragen an die Datenbank zu erzeugen. Selbst ein kleines Detail wie eine zufällige Verschiebung der TTL kann das Risiko erheblich verringern, dass alle Schlüssel gleichzeitig ablaufen.

Eine separate Kategorie von Problemen sind Retries. Wenn der Dienst ausfällt oder langsam antwortet, zwingt naive Retry-Logik die Clients, die Anfragen synchron zu wiederholen. Anstatt sich zu erholen, erhält das System einen noch größeren Schlag. Daher sind Verzögerungen, exponentielles Backoff und zufälliger Jitter keine Optimierung, sondern eine Notwendigkeit.

Thundering herd ist kein Bug im Code, sondern eine Folge architektonischer Entscheidungen. Es tritt dort auf, wo das System quantitativ skaliert, aber den Wettbewerb um gemeinsame Ressourcen nicht berücksichtigt. Wenn man nicht nur darüber nachdenkt, "wie es funktioniert", sondern auch darüber, "wie es sich unter Last verhält", kann man dieses Problem bereits in der Entwurfsphase vermeiden.