Describe a Nuxt server caching strategy for slow upstream APIs

What's really being asked

The interviewer wants to see if you understand Nuxt 3's Nitro server layer and can design a caching strategy that reduces latency without breaking consistency. They care about tradeoffs between speed and correctness, not just dropping in a cache.

The full answer

First, choose the right backend. In-memory LRU via unstorage with the memory driver works for single-instance deployments and sub-millisecond hits, but Redis via the redis driver is required for multi-instance or serverless consistency. Second, implement a server route handler or middleware that constructs a cache key from the request URL and query parameters, checks unstorage first, and only calls the upstream API on a miss. Third, set a TTL that matches data volatility. Fourth, handle cache stampede by adding a short lock or using stale-while-revalidate logic so concurrent requests do not hammer the upstream API when the cache expires. Fifth, discuss invalidation strategies like time-based eviction, manual purge endpoints, or tag-based invalidation if using Redis.

The mistakes people make

A red flag is suggesting only client-side caching or useAsyncData without server-side interception. Another is using a plain JavaScript object as a global cache on the server, which leaks memory and breaks in serverless environments. Proposing Redis without explaining why it beats in-memory for multi-instance setups shows shallow reasoning. Ignoring cache key design, such as forgetting to include query parameters or user tokens, leads to collisions and data leaks.

What usually comes next

The interviewer might ask how you would handle cache invalidation when upstream data changes, how to prevent memory leaks in long-running Node processes, or how to cache partial responses versus full payloads. They may also probe how you would monitor cache hit rates and TTL effectiveness in production.

A concrete example

Suppose a product detail page calls three upstream services for inventory, pricing, and reviews. You create a Nitro server route at api product detail that composes these calls. You wrap the upstream fetches with unstorage using a Redis driver keyed by product ID and data type. Inventory gets a 30-second TTL, pricing gets 60 seconds, and reviews get 5 minutes. On a cache miss, all three fetch in parallel with Promise all. You add a stale-while-revalidate header so the client can tolerate slightly old data while a background refresh happens. This drops p95 latency from 800ms to under 50ms for cached hits.