There are only two hard things in Computer Science: cache invalidation and naming things
— Phil Karlton, 1997
„Bei mir sieht’s gut aus. Hast du schon deinen Cache geleert?” — Dein Webdesigner, vor fünf Minuten.
2009 landete Made Media durch eine vertragliche Unachtsamkeit die Verantwortung für die Begleitwebsite einer der meistgesehenen Fernsehsendungen Großbritanniens. Besagte Website war die meistbesuchte Website von Channel 4 im ganzen Land – unter anderem, weil die Sendung es zur Tradition gemacht hatte, das Publikum live auf Sendung dorthin zu schicken und Rückmeldungen direkt einzubinden. Wir können aus eigener Erfahrung bestätigen, was passiert, wenn ein bekannter Fernseharzt zur Primetime auf eine Webseite mit einer Bildergalerie bestimmter Körperteile zeigt und das Publikum einlädt, sich online zu vergleichen. Die Bandbreitenkurve muss ihre Skalenachse innerhalb einer Sekunde verzehnfachen. Das Rechenzentrum ruft an und fragt, was zur Hölle gerade passiert.
Ein verdammt guter Server. Mit wahrscheinlich fast so viel Rechenleistung wie dein heutiges Smartphone.
Damals steckten wir noch die Zehen ins Wasser, was Amazon Web Services anging. Was wir hatten: ein Rack voller Webserver in einem Rechenzentrum in Manchester. Einen davon konnten wir für diese Website reservieren. Ein verdammt guter Server. Mit wahrscheinlich fast so viel Rechenleistung wie dein heutiges Smartphone. Einen Lasttest gab es nicht. Einen Notfallplan auch nicht.
Ich weiß nicht, was wir uns dabei gedacht haben – vielleicht den Server mit Wasser übergießen, falls er Feuer fängt.
Was wir taten: ein paar Artikel über den Umgang mit Denial-of-Service-Angriffen lesen. Und Punkt eins auf der Liste war ein Reverse-Proxy-Cache. Die Open-Source-Lösung, die alle empfahlen, hieß Varnish. Wir installierten sie, optimierten die Webserver-Konfiguration ein wenig und drückten die Daumen. Tatsächlich fuhren zwei von uns die M6 hoch nach Manchester. Ich weiß nicht, was wir uns dabei gedacht haben – vielleicht den Server mit Wasser übergießen, falls er Feuer fängt.
Die Website hielt auf diesem einzelnen Server stand – dank der Magie des Cachings. In Zeiten von Cloud-Computing und horizontal skalierenden Anwendungen gerät Caching leicht in den Hintergrund. Aber es ist nach wie vor entscheidend dafür, dass Websites stabil laufen.
Die Wahrheit ist: Die meisten Webseiten ändern sich gar nicht so oft. Und wenn doch, dann meist in vorhersehbaren Zeitfenstern. Selbst wenn man Inhalte nur eine Sekunde lang cachen kann, ist das enorm – bei mehr als 2.000 Anfragen pro Sekunde, etwa mitten im Vorverkaufsstart eines Ed-Sheeran-Konzerts.
Die meisten Web-Assets lassen sich cachen: eine Startseite, ein Kaufen-Button, ein Verfügbarkeits-Feed, ein JavaScript-Snippet oder ein Spielplan. Und man kann sehr genau steuern, wann ein Cache abläuft – ob durch „dieser Inhalt ist 60 Sekunden gültig” oder „dieser Status läuft um genau 10:00 Uhr ab, wenn der Vorverkauf startet”. HTTP-Caching ist im Grunde das Fundament der Internet-Infrastruktur. Die vielgepriesenen Content Delivery Networks sind im Wesentlichen nichts anderes als ein Netzwerk aus Reverse-Proxy-Caching-Servern wie Varnish. Das Problem: Die meisten Webentwickler:innen verstehen HTTP-Caching zwar halbwegs, investieren aber nicht die Arbeit, um sicherzustellen, dass es wirklich wie vorgesehen funktioniert – weil es schlicht mühsam ist.
Wir bauen Caching-Überlegungen von Anfang an in die Anwendungsarchitektur ein, anstatt sie nachträglich dranzuhängen.
Das Schlimmste, was man bei einer hochfrequentierten Anwendung tun kann: gut cachebaren Content (wie Verfügbarkeitsdaten) mit schwer cachebarem Content (wie persönlichen Nutzerdaten) zusammenzuschweißen. Wer diese Belange miteinander verkoppelt, macht seine gesamte Anwendung praktisch uncachebar. Wie ausgefallen die horizontal skalierende Architektur dabei auch ist – es spielt keine Rolle, denn wir haben gerade gezeigt, dass Caching Leistungsgewinne um den Faktor 2.000 erzielen kann. Selbst wenn die Cloud so schnell skalieren könnte (Spoiler: kann sie nicht), würde man dafür ein Vermögen bezahlen.
Bei Made Media bauen wir Caching-Überlegungen daher von Anfang an in die Anwendungsarchitektur ein, anstatt sie nachträglich dranzuhängen. Das macht die Entwicklung anspruchsvoller – aber wenn der Cache den Code bricht, muss der Code neu gedacht werden. Das ist es, was wir mit „Cache first, Fragen kommen später” meinen.