Ein heißer Cache-Key läuft ab und deine Datenbank geht in die Knie. Was ist passiert, und wie verhinderst du es?

Das ist eine Cache Stampede, manchmal Thundering Herd genannt. Tausende gleichzeitige Requests verfehlen im selben Moment den Cache und berechnen alle denselben Wert neu. Fix ist Single-Flight-Locking, sodass nur ein Worker neu berechnet, während die anderen warten oder veraltete Daten ausliefern. Ergänz Jitter auf den TTLs, damit Keys nicht gemeinsam ablaufen, refresh heiße Keys im Hintergrund vor dem Ablauf und liefer bei Fehlern veraltete Daten aus.

Das ist eine Stampede. Der Key läuft ab, zehntausend laufende Requests verfehlen gleichzeitig, und sie alle fahren dieselbe teure Query, die Datenbank sieht also zehntausend Kopien einer Query, die sie sonst einmal pro Minute sieht. Der erste Fix ist Coalescing, ein Single-Flight-Lock im Cache heißt, ein Worker berechnet neu und alle anderen warten auf dieses Ergebnis oder bekommen den veralteten Wert. Wir haben dafür ein Redis-SETNX-Lock mit kurzer TTL genutzt, und die Datenbanklast auf diesem Pfad ist um etwa zwei Größenordnungen gefallen. Obendrauf gebe ich jeder TTL Jitter, statt exakt 300 Sekunden also 300 plus minus 10%, was den Ablauf über Keys hinweg entkorreliert. Für wirklich heiße Keys bevorzuge ich probabilistische frühe Neuberechnung, bei der ein Request nahe am Ende der TTL im Hintergrund erneuert und weiter den gecachten Wert ausliefert. Und ich cache immer auch negative Ergebnisse, sonst wird aus einer fehlenden Zeile eine unbegrenzte Query-Schleife.