API caching with Redis & HTTP cache headers

Optimizing API performance and reducing server load is crucial for scalable full-stack applications. API caching achieves this by storing frequently accessed data, preventing redundant requests to the origin database or service. This significantly improves response times and reduces operational costs. A comprehensive caching strategy typically involves both server-side and client-side mechanisms, working in concert to deliver a fast and efficient user experience.

For server-side caching, Redis stands out as an excellent in-memory data store. When an API request comes in, the application first checks Redis. If the data is found (a cache hit), it's returned immediately. If not (a cache miss), the application fetches the data from its primary source (e.g., a database), stores it in Redis with an appropriate Time-To-Live (TTL) to ensure freshness, and then returns it. This pattern drastically reduces database load and server processing, especially for read-heavy operations, by serving responses directly from a lightning-fast cache.

Complementing server-side caching, HTTP cache headers enable client-side and CDN caching. Headers like Cache-Control (e.g., max-age, public, private, no-cache) instruct browsers and intermediate caches (like CDNs) on how long they can store a response and under what conditions. ETag and Last-Modified headers facilitate conditional requests: clients can send If-None-Match or If-Modified-Since to the server. If the data hasn't changed, the server responds with a 304 Not Modified status, avoiding the re-transmission of the entire response body and saving significant bandwidth.

Key Takeaways

Combine server-side (Redis) and client-side (HTTP headers) caching for optimal API performance.
Redis acts as a fast in-memory store, reducing database load and improving server response times.
HTTP Cache-Control headers instruct browsers/CDNs to cache responses, reducing network traffic and latency.
Use TTLs in Redis and Cache-Control's max-age to manage data freshness effectively.
Leverage ETag and conditional requests (If-None-Match) to prevent re-sending unchanged data, saving bandwidth.

Code Example

const express = require('express');
const redis = require('redis');
const app = express();

const redisClient = redis.createClient({ host: 'localhost', port: 6379 });
redisClient.on('error', (err) => console.log('Redis Client Error', err));
redisClient.connect();

app.get('/api/users/:id', async (req, res) => {
  const { id } = req.params;
  const cacheKey = `user:${id}`;
  const ONE_HOUR = 3600;

try {
    const cachedUser = await redisClient.get(cacheKey);
    if (cachedUser) {
      res.set('Cache-Control', 'public, max-age=60'); // Client cache for 60s
      return res.json(JSON.parse(cachedUser));
    }

const user = await fetchUserFromDB(id); // Simulate DB fetch
    await redisClient.setEx(cacheKey, ONE_HOUR, JSON.stringify(user));

res.set('Cache-Control', 'public, max-age=60');
    res.set('ETag', generateEtag(user));
    res.json(user);
  } catch (error) {
    res.status(500).send('Error fetching user');
  }
});

// Helper functions (simplified)
async function fetchUserFromDB(id) { return { id, name: `User ${id}`, email: `user${id}@example.com` }; }
function generateEtag(data) { return `"${require('crypto').createHash('md5').update(JSON.stringify(data)).digest('hex')}"`; }

app.listen(3000, () => console.log('Server running on port 3000'));

Preview

How this code works

This code sets up an Express API endpoint that serves user data, prioritizing fast delivery by using Redis for API caching and HTTP cache headers for client-side caching. It starts by configuring express and connecting to a Redis server using redis.createClient on localhost:6379, including an error listener for connection issues. The main route, app.get('/api/users/:id'), handles requests for specific user IDs, where a unique cacheKey is derived from the ID.

Inside the route, the server first attempts to retrieve the user data from Redis using redisClient.get(cacheKey). If found (if (cachedUser)), it immediately sends the parsed JSON data, setting an HTTP Cache-Control header with max-age=60 to instruct client browsers to cache it for 60 seconds. If not in Redis, the data is fetched from a simulated database via fetchUserFromDB(id). This fresh data is then stored in Redis using redisClient.setEx with a longer ONE_HOUR expiration. Finally, the response includes the Cache-Control header (again, max-age=60) and an ETag for further client-side validation. A subtle point for beginners is understanding the distinction between the server-side Redis cache duration (ONE_HOUR) and the client-side HTTP cache duration (max-age=60), as they operate at different layers of caching.

Resources

Hand-picked reads to go deeper on advanced api patterns.

Back to Full-Stack Developer Roadmap

This lesson is for enrolled learners

API caching with Redis & HTTP cache headers

Key Takeaways

Code Example

How this code works

Resources

Related Articles