Caching

Caching in der Web-App-Architektur

Beim Caching in einer Web-App-Architektur geht es primär darum, die Latenz zu verringern und die Last auf die Backend-Systeme (insbesondere die Datenbank) zu reduzieren. Man speichert Kopien von Daten in einem extrem schnellen Speichermedium (meist RAM), damit sie bei der nächsten Anfrage nicht erneut teuer berechnet oder aus einer langsameren Festplatte gelesen werden müssen.

Hier sind die Details zu den verschiedenen Ebenen und Strategien:

1. Die Caching-Ebenen

Caching findet an mehreren Stellen in der Architektur statt:

• Browser-Caching: Der Browser speichert statische Dateien (Bilder, Stylesheets) lokal auf dem Gerät des Nutzers.
• CDN-Caching (Edge Caching): Kopien von Dateien liegen auf Servern weltweit verteilt, nah am Nutzer.
• Application Caching (In-Memory): Daten werden direkt im Arbeitsspeicher des App-Servers vorgehalten.
• Distributed Caching (z.B. Redis, Memcached): Ein separater, zentraler Dienst, auf den alle App-Server zugreifen. Das ist der Standard für skalierbare Cloud-Apps.

2. Typische Anwendungsfälle für Distributed Caching

• Session Management: Speichern von Login-Informationen, damit der Nutzer eingeloggt bleibt, egal welcher App-Server seine Anfrage gerade bearbeitet.
• Datenbank-Query-Caching: Das Ergebnis einer komplexen SQL-Abfrage, die sich selten ändert, wird zwischengespeichert.
• API-Antworten: Wenn deine App Daten von Drittanbietern (z.B. Wetterdaten) bezieht, werden diese gecacht, um API-Limits zu sparen und die Geschwindigkeit zu erhöhen.

3. Caching-Strategien (Wie kommen die Daten in den Cache?)

Es gibt zwei Hauptansätze, wie die App mit dem Cache interagiert:

• Cache-Aside (Lazy Loading):

1. Die App sucht Daten im Cache.
2. Wenn nicht vorhanden (Cache Miss), liest sie die Daten aus der Datenbank.
3. Die App schreibt die Daten in den Cache und gibt sie an den Nutzer zurück.

Vorteil: Nur benötigte Daten landen im Cache.

• Write-Through:

1. Die App schreibt Daten gleichzeitig in die Datenbank und in den Cache.

Vorteil: Der Cache ist immer aktuell, aber Schreibvorgänge sind etwas langsamer.

4. Die größte Herausforderung: Cache-Invalidierung

Das schwierigste Problem beim Caching ist die Entscheidung, wann ein Eintrag gelöscht werden muss.

„There are only two hard things in Computer Science: cache invalidation and naming things“

Gängige Methoden sind:

• TTL (Time-to-Live): Jeder Eintrag bekommt ein Ablaufdatum (z.B. 5 Minuten). Danach wird er gelöscht.
• LRU (Least Recently Used): Wenn der Speicher voll ist, werden die Daten gelöscht, auf die am längsten nicht zugegriffen wurde.
• Explizite Löschung: Wenn ein Datensatz in der Datenbank aktualisiert wird, sendet die App einen Befehl, den entsprechenden Key im Cache sofort zu löschen.

5. Beispiel-Technologien in der Cloud

• Redis: Der Goldstandard. Unterstützt komplexe Datenstrukturen (Listen, Sets) und kann Daten sogar persistent auf Festplatte speichern.
• Memcached: Einfacher, rein auf Geschwindigkeit getrimmter Key-Value-Speicher.
• AWS ElastiCache / Azure Cache for Redis: Verwaltete Dienste, die das Setup und die Skalierung der Cache-Cluster übernehmen.

Zusammenfassend: Ohne Caching müsste die Datenbank bei jedem Klick jedes Nutzers arbeiten. Mit Caching "merkt" sich das System die Antworten, was die App massiv beschleunigt und Kosten spart, da die Datenbank kleiner dimensioniert werden kann.