CodeParkPut small, rarely changing data in an in-process cache, shared app data in Redis, and public HTTP responses in a CDN. Many systems use all three as layers.
In-process cache (a Map or an LRU cache in Node's memory) is the fastest option, because there is no network hop. Its downsides:
- Each instance has its own copy.
- It is lost on restart.
- It uses heap memory.
- It is hard to invalidate across instances.
It is good for small, rarely changing data like config or feature flags, with short TTLs (time to live: how long an entry stays).
Redis is one network hop away. That usually takes under a millisecond in the same data center. All instances share it, and it survives app restarts. It supports TTLs, atomic operations and invalidation. It is good for sessions, query results, rate limits and computed data shared across services.
CDN (content delivery network) caches HTTP responses at edge locations near users. Cache-Control headers control it. It removes that load from your servers completely and cuts latency for users far away. It is good for static assets and public responses that are the same for everyone. Purging is less precise, and per-user data does not belong there.
- An in-process cache is fastest, but each instance has its own copy and it is hard to invalidate.
- Redis is shared by all instances, costs a network hop and has rich operations.
- A CDN caches HTTP responses at the edge, driven by headers.
- Use a CDN for public static content and Redis for shared app data.
- Use all three as layers, with short TTLs on the in-process layer.