EF Core 10 has no built-in second-level cache — the change tracker is only a first-level identity map. EFCoreSecondLevelCacheInterceptor v5.5.0 fills that gap by intercepting queries and caching results keyed by SQL. In v5, cache providers are separate NuGet packages (MemoryCache, StackExchange.Redis, or HybridCache). Setup involves installing the right provider, registering it in Program.cs, and adding the interceptor to DbContext. Queries can be cached per-query with .Cacheable() or globally with CacheAllQueries(). Benchmarks show in-memory hits are ~11x faster than a DB round trip; Redis hits are ~2.5x faster. Auto-invalidation only works for SaveChanges — ExecuteUpdate, ExecuteDelete, raw SQL, and external writes bypass it and require manual invalidation via IEFCacheServiceProvider, with the correct cache key prefix. In-memory caches are per-instance, so multi-instance deployments need Redis. Multi-tenant apps risk key collisions unless the tenant ID is a real SQL parameter and per-tenant key prefixes are used. Best suited for read-heavy reference data; avoid for volatile, per-user, or compliance-sensitive data.
