API Caching

You are a backend API developer implementing a caching strategy. The user wants to add a caching layer to API responses to reduce database load and improve response times.

What to check first

• Verify your API framework (Express, FastAPI, Django, etc.) and whether you're using Node.js, Python, or another runtime
• Check if Redis or Memcached is running locally: redis-cli ping should return PONG
• Inspect existing API routes to identify which endpoints benefit most from caching (typically GET requests with heavy queries)

Steps

1. Install a caching client library matching your stack (redis for Node.js, redis-py for Python, or django-redis for Django)
2. Configure cache connection parameters (host, port, TTL defaults) in environment variables or config file
3. Create a cache wrapper function or decorator that checks cache before executing the main handler
4. Add serialization logic to convert response objects to cacheable formats (JSON strings for Redis)
5. Implement cache invalidation strategy — decide TTL (time-to-live) for different endpoint types
6. Add cache key generation based on endpoint path and query parameters to prevent collision
7. Wrap expensive database queries or external API calls with the cache check
8. Test cache hits by calling the same endpoint twice and measuring response time difference

Code

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

// Initialize Redis client
const client = redis.createClient({
  host: process.env.REDIS_HOST || 'localhost',
  port: process.env.REDIS_PORT || 6379,
});

client.on('error', (err) => console.error('Redis error:', err));

// Cache key generator
function generateCacheKey(endpoint, query) {
  const queryStr = JSON.stringify(query);
  return `${endpoint}:${queryStr}`;
}

// Cache middleware with configurable TTL
function cacheMiddleware(ttl = 300) {
  return async (req, res, next) => {
    const cacheKey = generateCacheKey(req.path, req.query);
    
    try {
      const cachedData = await client.get(cacheKey);
      
      if (cachedData) {
        console.log(`Cache HIT for ${cacheKey}`);
        return res.json(JSON.parse(cachedData));
      }
    } catch (err) {
      console.warn('Cache retrieval error:', err);
    }
    
    // Store original res.json to intercept response
    const originalJson = res.json.bind(res);
    
    res.json = function(data) {
      try {
        client.setex(cacheKey, ttl, JSON.stringify(data));
      } catch (err) {
        console.warn('Cache write error:', err);
      }
      return originalJson(data);
    };
    
    next();
  };
}

// Cache invalidation

Note: this example was truncated in the source. See the GitHub repo for the latest full version.

Common Pitfalls

• Not validating request bodies before processing — attackers will send malformed payloads to crash your service
• Returning detailed error messages in production — leaks internal architecture to attackers
• Forgetting CORS headers — frontend will silently fail with cryptic browser errors
• Hardcoding API keys in code — use environment variables and secret management
• No rate limiting — one client can DoS your entire API

When NOT to Use This Skill

• When a single shared library would suffice — APIs add network latency and failure modes
• For internal-only data flow within the same process — use direct function calls
• When you need transactional consistency across services — APIs can't guarantee this without distributed transactions

How to Verify It Worked

• Test all CRUD operations end-to-end including error cases (404, 401, 403, 500)
• Run an OWASP ZAP scan against your API — catches common security issues automatically
• Load test with k6 or Artillery — verify your API holds up under realistic traffic
• Verify rate limits actually trigger when exceeded — they often don't due to misconfiguration

Production Considerations

• Version your API from day one (/v1/) — breaking changes are inevitable, give yourself a path
• Set request size limits — prevents memory exhaustion attacks
• Add structured logging with request IDs — trace every request across your stack
• Document your API with OpenAPI — generates client SDKs and interactive docs for free