Caching Strategy for High Volume Personalized Content Requests
summary
MLB moves from in-memory defaults to a shared Redis cache, APQ + GET requests through CDN, and response-cache plugin to handle spikes that reached ~15 million requests/hour and now ~35 million/day with ~80% cache hits. Key fixes: split private user queries from public data, set field-level Cache-Control TTLs (e.g. live line score 20s), override data-source TTLs on 404s, upgrade Gateway to stop empty subgraph calls, and fix unbounded in-memory caching that caused OOMs. APQ GET requests shared Redis cache Gateway version bump
AI-written summary · about
chapters (10)
- 0:00Introduction to MLB caching
- 4:34Layered caching strategy
- 8:44Team snapshot view caching
- 11:13My news personalized view
- 13:59My follows view issues
- 15:27Stories view cache behavior
- 18:16Standings module cache gaps
- 19:42Key takeaways and lessons
- 21:51Current system overview
- 22:55Q&A and closing
related talks
25mCaching strategies on https://dev.to
36mMake It Fast
37mCaching Deep Dive: The Ultimate Way To Speed up Your GraphQL API
23mHow to edge cache GraphQL APIs
49mUnlocking Performance with Response Caching
31mFifty Shades of Caching and How LLMs Paint It Blαck
26mCache Strategies with Best Practices
43mCaching half a billion user transactions