Wasserfall vs. parallel
Vier unabhängige Abfragen von je etwa 60ms — erst nacheinander abgewartet, dann alle gleichzeitig.
Velocity
Latenz beseitigen als Architektur, nicht als Trickkiste: optimistische Mutationen, Cache-Stufen, Stampede-Schutz, verschobene Nacharbeit — jeweils gegen die naive Variante gemessen.
Jede Zahl auf dieser Seite wurde bei der Anfrage gemessen, die sie angefordert hat. Nichts davon ist ein gespeicherter Wert.
Nebenläufig — eine Seite über Wasserfälle sollte keinen erzeugen.
Kalt, warm, gecacht
Derselbe Wert dreimal gelesen: jedes Mal neu berechnet, dann über den Cache gelesen. Jeder Zugriff kostet am Origin etwa 60ms.
Stale while revalidate
Zwei Policies, ein Wert, beide über eine TTL von 1s hinaus gealtert. Die eine erklärt ein Stale-Fenster, die andere nicht. Dauert etwa 1200ms — diese Wartezeit IST das Ablaufen der TTL.
Cache-Stampede
100 gleichzeitige Fehlzugriffe auf einen Wert. Lies die Origin-Aufrufe, nicht die Uhr — das ist es, was die Abhängigkeit tatsächlich abbekommen hat.
Verschobene Nacharbeit
Ein Schreibvorgang von etwa 60ms plus drei Folgewirkungen: erst vor der Antwort abgewartet, dann danach verschoben.
Simuliert ist die Abhängigkeit — sie schläft, statt Postgres abzufragen, damit eine öffentliche Seite die Datenbank nicht belasten kann und feste Kosten beide Varianten vergleichbar halten. Die Mechanismen sind echt.
Geht dieses Pattern noch besser? Sag uns, wie.
Feedback geben