Wie würdest du einen Cache vor einen leselastigen Endpoint setzen, ohne stark veraltete Daten auszuliefern?

Nimm die kürzeste TTL, die noch etwas bringt, und invalidiere beim Schreiben, indem du den Key in demselben Pfad löschst oder überschreibst, der die Zeile ändert. Bilde den Key aus jeder Eingabe, die das Ergebnis verändert, inklusive Mandant und Schema-Version. Ergänz Single-Flight-Locking, damit ein Miss die Datenbank nicht überrennt. Akzeptier bewusste Veraltung, wo sie harmlos ist, und verfolge die Trefferquote, damit du weißt, dass es funktioniert.

Bevor ich irgendetwas ergänze, prüfe ich, ob sich die Query nicht einfach schnell machen lässt, denn ein Cache vor einer schlechten Query verbirgt das Problem, bis der Cache im ungünstigsten Moment nicht trifft. Angenommen, es ist wirklich leselastig, dann gehe ich mit Cache-aside in Redis. Der Key enthält die Mandanten-Id, die tatsächlichen Query-Parameter und ein Versionspräfix, das ich beim Deploy hochziehen kann, damit eine geänderte Antwortform nie aus alten Einträgen ausgeliefert wird. Die TTL ist das Sicherheitsnetz und nicht der Mechanismus: ich invalidiere explizit beim Schreiben, in demselben Codepfad, der die Zeile aktualisiert, das Veraltungsfenster ist im Normalfall also Millisekunden. Der Fehlermodus, für den ich plane, ist der Ansturm, bei dem ein heißer Key abläuft und zweihundert Requests gleichzeitig danebengreifen und die Datenbank treffen, ich nutze also ein Single-Flight-Lock und lasse die Verlierer auf den Gewinner warten. Danach exportiere ich die Trefferquote als Metrik, denn ein Cache, der nach einem Refactor von 95 Prozent auf 10 gefallen ist, fällt niemandem auf, bis die Datenbank umkippt.