Wie würdest du ein CDN vor eine dynamische Anwendung setzen?

Cache aggressiv, was sicher ist, und geh beim Rest chirurgisch vor. Gib statischen Assets Dateinamen mit Fingerprint und eine sehr lange Max Age, dann sind sie für immer gecacht und werden über einen neuen Namen invalidiert. Für dynamische Responses nimm kurze Lebensdauern mit stale-while-revalidate und halt den Cache Key minimal, denn jedes Cookie oder jeden Query-Parameter aufzunehmen zerstört die Hit Rate. Terminier TLS an der Kante und leg Firewall und Rate Limiting auch dorthin.

Statische Assets sind der einfache Gewinn: Dateiname mit Content-Hash als Fingerprint, ein Jahr cachen und nie invalidieren, denn eine Änderung erzeugt einen neuen Namen. Wenn du das richtig machst, erreichen die meisten deiner Bytes nie den Origin. Dynamische Responses brauchen mehr Sorgfalt. Der Cache Key ist das, was Leute falsch machen: wenn das CDN auf jedes Cookie und jeden Query-Parameter keyt, gibt ein Session-Cookie oder ein Tracking-Parameter jedem Nutzer seinen eigenen Eintrag und die Hit Rate bricht zusammen. Ich stutze den Key also auf das zurecht, was die Response wirklich verändert, und normalisiere den Rest. Für Inhalte, die für alle gleich sind, sich aber gelegentlich ändern, etwa eine Produktseite, holt eine kurze Lebensdauer plus stale-while-revalidate fast den ganzen Nutzen bei tolerierbarer Veralterung, und ich nutze Tags, sodass ein Publish genau die betroffenen Seiten purgen kann. Wirklich personalisierte Inhalte umgehen entweder den Cache oder werden an der Kante aus einer gecachten Hülle zusammengesetzt. Obendrauf terminiert TLS an der Kante, Komprimierung passiert dort, und Firewall und Rate Limiting sitzen ebenfalls dort, was eine Menge Lärm komplett vom Origin fernhält.