> Markdown version of [/videos/433-event-based-cache-invalidation-in-graphql](https://www.wearedevelopers.com/videos/433-event-based-cache-invalidation-in-graphql). Every page supports `.md` or `Accept: text/markdown`. Links point to the HTML versions so they work for humans too. Agent guide: [/agents.md](https://www.wearedevelopers.com/agents.md).

---

# Event based cache invalidation in GraphQL

Simi San Fratello reveals the ultimate fix for stale GraphQL data. Master true event-based cache invalidation using Redis and Mercurius to keep interactive apps perfectly synchronized.

- **Speakers:** Simone Sanfratello
- **Event:** World Congress 2022
- **Published:** June 15, 2022
- **Duration:** 36:58
- **URL:** https://www.wearedevelopers.com/videos/433-event-based-cache-invalidation-in-graphql

## Summary

Simi San Fratello, maintainer of mercurius-cache, tackles the complex challenge of cache invalidation within GraphQL APIs. Treating GraphQL resolvers as pure, memoizable functions forms the baseline for caching, but developers must strategically choose between time-based and event-based mechanisms. While time-based approaches with a predetermined time-to-live (TTL) perform exceptionally well for static content like geographic data, event-based invalidation is crucial for keeping highly interactive, live application data synchronized natively when underlying source databases change.

Building a robust caching layer requires pairing efficient key-value storage—such as synchronous in-memory caches for small runtime data or Redis for scaling across distributed Node.js applications—with targeted invalidation mapping. By serializing queries to create unique hash keys and associating them with auxiliary data tags known as references, applications essentially index their cache. When a GraphQL mutation updates a source record, the system uses these targeted reference links to instantly locate and evict the related, stale query entries from caching storage.

Implementing these patterns using Fastify, Mercurius, and Redis illustrates how to configure policy-driven caching structures, define custom reference tags directly inside queries, and trigger automated purges via mutation resolvers. Moving toward production-grade caching requires developers to address architectural bottlenecks, such as utilizing asynchronous request deduplication to prevent database flooding during concurrent queries, customizing serialization to avoid nested JSON parsing lags, and strictly pairing caching logic with Data Loaders to prevent standard GraphQL N+1 query problems.

**Keywords:** graphql cache invalidation, event-based caching strategy, time-based TTL expiration, mercurius-cache plugin, fastify backend integration, graphql resolver memoization, redis storage synchronization, in-memory cache routing, target caching references, cache key serialization, graphql mutation triggers, async cache deduplication, graphql dataloaders n+1, distributed nodejs state

## Chapters

1. **Introduction to GraphQL resolvers and the Mercurius ecosystem** (00:05) — Treating GraphQL resolvers as pure functions provides a foundation for effective memoization.
1. **Balancing time-based expiration and event-based caching strategies** (02:43) — Comparing scheduled expiration against write-event triggers reveals different tradeoffs for data consistency.
1. **Selecting optimal caching approaches based on data volatility** (06:00) — Static reference lists suit scheduled refreshes while live application settings require immediate event updates.
1. **Comparing in-memory and Redis storage for cache scalability** (07:43) — Redis enables shared caching across multiple application instances while in-memory storage serves lightweight repetitive entries.
1. **Targeting cache entries using reference indexes in Mercurius** (11:25) — Linking serialization keys to entity references allows precise cache invalidation upon data writes.
1. **Setting up a baseline GraphQL API in Fastify** (14:57) — Defining schemas and basic resolvers establishes the necessary infrastructure for testing cache implementations.
1. **Configuring default caching policies and storage in Mercurius** (21:48) — Applying specific expiration durations and storage types at the query level isolates caching behaviors.
1. **Implementing event-based cache invalidation for updated mutations** (26:41) — Returning referenced entity identifiers from mutation resolvers successfully clears stale associated records.
1. **Optimizing concurrent requests via asynchronous cache deduplication** (29:52) — Resolving duplicated concurrent requests through shared promises stops redundant database queries under load.
1. **Addressing the N+1 problem and partial query caching** (33:50) — Applying dataloaders at the resolver level prevents severe performance bottlenecks when fetching associated nodes.

## Related Moments

- [Solving data fetching demands with GraphQL](https://www.wearedevelopers.com/videos/100247-rest-graphql-grpc-and-more-a-comparison-of-modern-api-styles) (from "REST, GraphQL, gRPC, and more: A comparison of modern API styles")
- [Mitigating security risks and expensive computational joins in GraphQL](https://www.wearedevelopers.com/videos/1054-graphql-does-it-replace-sql-rest-or-something-else) (from "GraphQL: Does it replace SQL, REST or Something Else?")
- [Optimizing performance across JSON methodologies and backend stacks](https://www.wearedevelopers.com/videos/33-api-design-getting-started) (from "API Design - Getting Started")
- [Answering questions on content cache invalidation and storage](https://www.wearedevelopers.com/videos/645-offline-first) (from "Offline first!")
- [Managing content scale and cache invalidation bottlenecks](https://www.wearedevelopers.com/videos/418-how-gatsby-cloud-s-real-time-streaming-architecture-drives-5-second-builds) (from "How Gatsby Cloud's real-time streaming architecture drives <5 second builds")
- [Exploring the n+1 query problem with naive resolvers](https://www.wearedevelopers.com/videos/257-putting-the-graph-in-graphql-with-the-neo4j-graphql-library) (from "Putting the Graph In GraphQL With The Neo4j GraphQL Library")

## Related Articles

- [Dev Digest 139 - Soft and hard queries](https://www.wearedevelopers.com/magazine/487-dev-digest-139-soft-and-hard-queries)
- [Dev Digest 120 - Apple and peers](https://www.wearedevelopers.com/magazine/455-dev-digest-120-apple-and-peers)
- [Introducing Redis Agent Memory Server](https://www.wearedevelopers.com/magazine/699-introducing-redis-agent-memory-server)
- [Dev Digest 138 - Are you secure about this?](https://www.wearedevelopers.com/magazine/486-dev-digest-138-are-you-secure-about-this)

## Related Jobs

- [Staff Frontend Engineer](https://www.wearedevelopers.com/jobs/48313-staff-frontend-engineer) at **SMG Swiss Marketplace Group**
- [Junior Frontend Engineer](https://www.wearedevelopers.com/jobs/ext/1532351-junior-frontend-engineer) at **Almedia**
- [Staff Frontend Engineer (Expert+/Lead equivalent) - Hybrid working model, 100%, Ho Chi Minh City](https://www.wearedevelopers.com/jobs/48314-staff-frontend-engineer-expert-lead-equivalent-hybrid-working-model-100-ho-chi-minh-city) at **SMG Swiss Marketplace Group**
- [Mid/Senior Full-Stack Engineer (Web-first)](https://www.wearedevelopers.com/jobs/ext/1210833-mid-senior-full-stack-engineer-web-first) at **SMG Swiss Marketplace Group**
- [Principal Engineer - AI Search & Vector Infrastructure](https://www.wearedevelopers.com/jobs/ext/353953-principal-engineer-ai-search-vector-infrastructure) at **Redis**
- [Agile Full Stack Engineer](https://www.wearedevelopers.com/jobs/48325-agile-full-stack-engineer) at **synava GmbH**