Adding Redis is easy.
Knowing when the cached data becomes wrong is the real work.
Before caching, define:
<ul>
<li>The cache key</li>
<li>The time-to-live</li>
<li>The invalidation trigger</li>
<li>The acceptable staleness</li>
<li>What happens when Redis is unavailable</li>
</ul>
Include tenants and query parameters in your keys.
Do not use caching to hide a database query that should be fixed.
What is harder in your application: invalidation or designing the correct cache key?
#NestJS #Redis #Caching

Smiley Face

Welcome to the NestJS Developers Hub, a collaborative community for developers passionate about NestJS! Whether you're a seasoned expert or just getting started, this group is dedicated to sharing knowledge, solving problems, and advancing our skills

Nestjs Developers

Discusses the design considerations that matter more than simply adding Redis caching to an application: defining cache keys (including tenant and query parameters), setting TTLs, planning invalidation triggers, deciding acceptable staleness, and handling Redis downtime gracefully. Warns against using caching to mask underlying slow database queries and poses a discussion question about whether invalidation or key design is harder.

Day 19/30 — Cache with a Plan