Ein beliebter Cache-Key läuft ab, und hunderte Requests treffen gleichzeitig die Datenbank. Wie verhinderst du das?

Verhinder die Stampede mit Single Flight: der erste Request, der danebengreift, nimmt ein kurzes Lock und rechnet neu, während die anderen kurz warten oder den veralteten Wert bekommen. Kombinier das mit Stale-while-revalidate, sodass ein abgelaufener Eintrag weiter ausgeliefert wird, während im Hintergrund ein Refresh läuft, und pack Jitter auf die Time-to-live-Werte, damit gemeinsam erzeugte Keys nicht gemeinsam ablaufen. Bei bekannten Hot Keys aktualisierst du proaktiv vor dem Ablauf.

Das Muster ist eine Thundering Herd: ein Hot Key läuft ab, und jeder gleichzeitige Request greift im selben Moment daneben, sie fahren also alle dieselbe teure Query. Der Kernfix ist Single Flight, wo der erste Miss ein kurzlebiges Lock auf dem Key nimmt und die Arbeit macht, und alle anderen entweder auf das Ergebnis warten oder kurz den veralteten Wert bekommen. Das kombiniere ich mit weichem Ablauf: ich speichere eine logische Refresh-Zeit im Wert und halte die harte Time-to-live länger, ein Eintrag jenseits seiner Refresh-Zeit wird also weiter ausgeliefert, während ein Worker ihn im Hintergrund neu berechnet. Nutzer sehen die Latenz überhaupt nicht. Dann Jitter, denn wenn ein Deploy tausend Keys mit derselben Time-to-live von fünf Minuten warmläuft, laufen sie gemeinsam ab, und ich bekomme die Stampede über den ganzen Cache auf einmal. Die größere Frage danach ist, was passiert, wenn der Cache komplett leer ist, nach einem Neustart oder einem Failover. Ich will, dass die Datenbank das übersteht, also lasttest ich mindestens einmal mit deaktiviertem Cache.