Cache stores (memory, Redis) in NestJS - Deep Dive

Overview - Cache stores (memory, Redis)

What is it?

Cache stores are systems that temporarily save data to speed up future access. In NestJS, common cache stores include in-memory storage and Redis, a fast external database. They help reduce repeated work by keeping frequently used data ready to use. This makes applications faster and more efficient.

Why it matters

Without cache stores, applications would repeatedly fetch or compute the same data, causing delays and higher server load. This can make websites slow and frustrating for users. Cache stores improve performance and scalability, making apps feel quick and responsive even under heavy use.

Where it fits

Before learning cache stores, you should understand basic NestJS concepts like modules and services. After mastering cache stores, you can explore advanced topics like distributed caching, cache invalidation strategies, and performance tuning.

Mental Model

Core Idea

Cache stores keep copies of data in a fast place so your app doesn’t have to fetch or calculate it again.

Think of it like...

Imagine a kitchen where you keep your favorite snacks on the counter instead of the pantry. When you want a snack, grabbing it from the counter is much faster than walking to the pantry every time.

┌───────────────┐       ┌───────────────┐
│  Application  │──────▶│ Cache Store   │
│ (NestJS App)  │       │ (Memory/Redis)│
└───────────────┘       └───────────────┘
         │                      ▲
         │                      │
         ▼                      │
   ┌───────────────┐            │
   │  Database or  │────────────┘
   │  External API │
   └───────────────┘

Build-Up - 7 Steps

1

Foundation

What is caching in NestJS

Concept: Introduce the basic idea of caching and how NestJS supports it.

Caching means saving data temporarily to avoid repeating slow operations. NestJS provides a CacheModule that you can import to add caching easily. By default, it uses an in-memory store that keeps data inside the app’s memory.

Result

You can store and retrieve data quickly within your NestJS app using the CacheModule.

Understanding caching as a way to save time and resources is key to improving app performance.

2

Foundation

In-memory cache store basics

Concept: Explain how the default in-memory cache works and its limits.

The in-memory cache keeps data inside the app’s RAM. It is very fast but only lasts as long as the app runs. If the app restarts, the cache is lost. It is good for simple, single-instance apps.

Result

Fast data access during app runtime but no persistence across restarts.

Knowing the volatility of in-memory cache helps decide when it’s suitable.

3

Intermediate

Using Redis as a cache store

🤔Before reading on: do you think Redis cache is faster or slower than in-memory cache? Commit to your answer.

Concept: Introduce Redis as an external cache store that persists data and supports multiple app instances.

Redis is a separate fast database designed for caching. It stores data in memory but runs outside your app. NestJS can connect to Redis using a cache manager adapter. Redis keeps data even if your app restarts and works well for apps running on many servers.

Result

Your app can share cached data across instances and keep it after restarts.

Understanding Redis as a shared, persistent cache store unlocks scalable app design.

4

Intermediate

Configuring CacheModule with Redis

🤔Before reading on: do you think configuring Redis cache requires code changes or just config files? Commit to your answer.

Concept: Show how to set up NestJS CacheModule to use Redis instead of memory.

You install Redis and a Redis client library. Then, import CacheModule with a Redis store option, providing connection details. This replaces the default memory store with Redis.

Result

Cache operations now use Redis transparently without changing your caching code.

Knowing how to swap cache stores by configuration helps adapt apps to different environments.

5

Intermediate

Cache keys and TTL explained

🤔Before reading on: do you think cache keys must be unique per data item or can they be reused? Commit to your answer.

Concept: Explain how cache keys identify stored data and TTL controls cache expiration.

Each cached item has a unique key string. When you request data, you use the key to find it. TTL (time-to-live) sets how long data stays in cache before it’s removed automatically. This prevents stale data.

Result

You can control cache freshness and avoid conflicts by managing keys and TTL.

Understanding keys and TTL is essential to effective cache management and data accuracy.

6

Advanced

Cache invalidation strategies

🤔Before reading on: do you think cache invalidation is simple or one of the hardest problems in caching? Commit to your answer.

Concept: Discuss ways to keep cache data accurate by removing or updating entries when source data changes.

Invalidation means removing or updating cached data when it becomes outdated. Strategies include manual invalidation after updates, automatic TTL expiry, or event-driven cache refresh. Choosing the right method depends on app needs.

Result

Your cache stays reliable and consistent with the main data source.

Knowing cache invalidation challenges prevents bugs and stale data in production.

7

Expert

Distributed caching and consistency challenges

🤔Before reading on: do you think distributed caches always guarantee data consistency? Commit to your answer.

Concept: Explore how distributed caches like Redis handle multiple app instances and the complexity of keeping data consistent.

When many app servers share a Redis cache, they must coordinate cache updates to avoid conflicts. Network delays and race conditions can cause stale or inconsistent data. Techniques like cache locking, versioning, or write-through caches help manage this complexity.

Result

Your app can scale horizontally with a shared cache but must handle consistency carefully.

Understanding distributed cache challenges is critical for building reliable, scalable systems.

Under the Hood

NestJS CacheModule uses a cache manager interface that abstracts different cache stores. For in-memory cache, it stores data in a JavaScript Map object inside the app process. For Redis, it sends commands over the network to the Redis server, which stores data in memory with optional persistence. Cache reads check the store for keys; writes add or update entries with TTL metadata. Expired entries are removed automatically by the store.

Why designed this way?

NestJS separates cache logic from storage to allow flexibility. In-memory cache is simple and fast for small apps. Redis was chosen as a popular, battle-tested external cache that supports persistence, clustering, and advanced features. This design lets developers pick the best cache store for their needs without changing app code.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│ NestJS Cache  │──────▶│ Cache Manager │──────▶│ Cache Store   │
│ Module        │       │ Interface     │       │ (Memory/Redis)│
└───────────────┘       └───────────────┘       └───────────────┘
         │                      │                      │
         ▼                      ▼                      ▼
  Cache API calls        Abstract methods       Data stored in
  (get, set, del)        (get, set, del)        memory or Redis

Myth Busters - 4 Common Misconceptions

Quick: Is in-memory cache shared across multiple app servers? Commit to yes or no.

Common Belief: In-memory cache is shared across all app instances automatically.

Reality: In-memory cache is local to each app instance and not shared across servers.

Why it matters: Assuming shared cache causes bugs where data is inconsistent between servers.

Quick: Does Redis cache guarantee data is always fresh? Commit to yes or no.

Common Belief: Redis cache always has the latest data from the database.

Reality: Redis cache can have stale data if invalidation or updates are not handled properly.

Why it matters: Relying on cache freshness without invalidation leads to showing outdated information.

Quick: Is caching only about speed? Commit to yes or no.

Common Belief: Caching is only for making things faster.

Reality: Caching also reduces load on databases and external services, improving scalability and reliability.

Why it matters: Ignoring caching’s role in reducing system load can cause performance bottlenecks.

Quick: Can you use the same cache key for different data? Commit to yes or no.

Common Belief: Cache keys can be reused for different data without issues.

Reality: Cache keys must be unique per data item to avoid overwriting and conflicts.

Why it matters: Reusing keys causes wrong data to be served, leading to bugs and confusion.

Expert Zone

1

Redis supports advanced data structures like hashes and sorted sets that can be used for complex caching patterns beyond simple key-value pairs.

2

Cache warming, preloading data into cache before it’s requested, can prevent slow responses on first access but requires careful timing and resource planning.

3

Using cache tags or namespaces helps group related cache entries for efficient bulk invalidation, a technique often missed by beginners.

When NOT to use

Avoid caching when data changes very frequently and must always be fresh, such as real-time stock prices or live chat messages. Instead, use direct database queries or streaming updates. Also, do not use in-memory cache for multi-server apps needing shared state; prefer Redis or other distributed caches.

Production Patterns

In production, apps often use Redis with TTL and manual invalidation triggered by database events. They combine cache-aside pattern where app checks cache first, then database if missing. Monitoring cache hit rates and setting alerts for cache failures is common. Some use layered caches: local in-memory for ultra-fast access plus Redis for shared state.

Connections

Database indexing

Both caching and indexing speed up data retrieval but work at different layers.

Understanding caching alongside indexing helps optimize overall data access performance.

Operating system page cache

OS page cache and application cache both store data in memory to avoid slow disk reads.

Knowing OS-level caching clarifies why application caching is still needed for business data.

Human memory recall

Caching is like how humans remember recent information to avoid rethinking everything.

This connection helps appreciate caching as a natural efficiency strategy, not just a technical trick.

Common Pitfalls

#1 Assuming cache always has fresh data and never updating it.

Wrong approach:

const value = await cacheManager.get('user_123'); // never refreshes after initial set

Correct approach:

await cacheManager.del('user_123'); // invalidate cache after user data changes
const value = await cacheManager.get('user_123');

Root cause:

Misunderstanding that cache is a temporary copy needing manual or automatic refresh.

#2 Using the same cache key for different data items.

Wrong approach:

await cacheManager.set('data', userData);
await cacheManager.set('data', productData);

Correct approach:

await cacheManager.set('user_123', userData);
await cacheManager.set('product_456', productData);

Root cause:

Not realizing cache keys must uniquely identify each cached item.

#3 Using in-memory cache in a multi-server environment expecting shared cache.

Wrong approach:

import { CacheModule } from '@nestjs/common';
CacheModule.register(), // default memory cache used on all servers

Correct approach:

CacheModule.register({
store: redisStore,
host: 'redis-host',
port: 6379
}),

Root cause:

Confusing local memory cache with distributed cache needed for multiple app instances.

Key Takeaways

Cache stores temporarily save data to speed up repeated access and reduce load.

In-memory cache is fast but local and volatile; Redis is external, persistent, and shared.

Cache keys uniquely identify data; TTL controls how long data stays fresh in cache.

Cache invalidation is critical to prevent stale data and maintain consistency.

Distributed caching introduces complexity in consistency but enables scalable applications.