How to edge cache GraphQL APIs
summary
A wartime scaling story turns into a concrete pattern: public, read‑heavy GraphQL (about 95% reads) causes DB overload when a real‑time DB crashes past ~50–100 change listeners, so the solution is to run normalized GraphQL caching at the edge. Implementation uses Fastly Compute@edge and GraphCDN to share and purge caches across ~60+ POPs, achieving a 150 ms global purge for object invalidation; result: large hit rate gains for workloads that change minutes to hours apart.
AI-written summary · about
chapters (5)
- 0:00Start
- 13:37Manual invalidation
- 14:40Normalized caching
- 17:15GraphQL is awesome for caching!
- 18:09Authorization
related talks
23mHow to Edge Cache GraphQL APIs
24mHow to cache GraphQL queries at the edge
37mCaching Deep Dive: The Ultimate Way To Speed up Your GraphQL API
25mGraphQL and caching - Why is it so hard, or is it? 
31mLessons from Scaling GraphQL to Half a Billion Requests per Minute
26mBuild a performance-optimized GraphQL API
12mHow @Defer and @Stream Will Improve GraphQL Caching
52mBuild and Deploy Instant GraphQL APIs to the Edge