Regular Caching

Drupal Internal Cache

• Usually completely transparent
  • No need to worry about purging
• Caches many many things
• Uses Cache Tags
• Stored in MySQL or Key-Value Storage
• Still does a full Drupal Bootstrap
• Also for authenticated Users (D8)
• Not the focus of today :)

External Caching (Reverse Proxy)

• 99.9% Varnish
• Only for anonymous users (pass if Session Cookie exists)
• Super Fast
• Mostly Memory Only

Cache Tags (D8 only)

• Each Entity has a tag

  • node:7, comment:1056

• All tags are added to the header of response
• Cache System stores them
• If Entity is updated: Drupal purges the tag

URL Purging

• Older way of purging based on URLs
• Very inefficient and error prune
• Don't use it anymore please

Decoupled Caching

Decoupled Caching

• Two Cache Layers:
  Frontend and Backend
• Only really works with Cache Tags
• Both Cache Layers need to be purged

GraphQL Caching

• GraphQL runs POST Requests
• POST Requests usually not cache-able
• Query Maps to the rescue

GraphQL Query Maps

1. Frontend Generates all possible GraphQL Queries
2. Writes JSON file with Queries as IDs
3. Hash per Query Map
4. Passes Query Map into Drupal (File or via API)
5. GraphQL Request with Hash and ID

Requests via GET with a Query Map Hash and Query ID

GraphQL Query Maps

• Disable POST all together in Production (security FTW)
• Enable POST during Development
• Query Map Generation fully automated in Build Processes
• Source of failure!

CDNs

CDNs

• Freaking awesome if they work correctly
• "Just" replace the Varnish Layer
• Need purging as well!

CDNs pitfalls

• Max Header Size for Cache Tags by CDNs
  • Reduce Cache Tag Header with Hashing or remove specific cache tags

CDNs pitfalls

• Have CDNs on Staging environments!
• You will thank me later

CDNs pitfalls

• Configuration of CDN in Code!
  • Making sure same config everywhere

CDNs pitfalls

• Can your infrastructure handle a 0% Cache Hit Rate?
• Metrics & Alertings on Cache Hit Rate