Microservices Caching Patterns: Complete Architecture Guide

Caching in microservices is fundamentally different from monolithic applications. With dozens of services, each potentially caching data, you face challenges around consistency, coordination, and cache invalidation across service boundaries.

This guide covers proven patterns for implementing caching in microservices architectures.

The Microservices Caching Challenge

In monoliths, caching is straightforward—one application, one cache. Microservices introduce complexity:

• Data ownership: Which service owns which cached data?
• Cross-service consistency: How do you invalidate when data changes?
• Network overhead: Remote cache calls add latency
• Failure isolation: Cache failures shouldn't cascade

Pattern 1: Service-Local Caching

// Order Service caches its own orders
class OrderService {
    constructor() {
        this.cache = new LocalCache({ maxSize: 10000 });
    }

    async getOrder(orderId) {
        const cached = this.cache.get(`order:${orderId}`);
        if (cached) return cached;

        const order = await this.db.findOrder(orderId);
        this.cache.set(`order:${orderId}`, order, { ttl: 300 });
        return order;
    }
}

Pros: Simple, no network calls, failure isolated

Cons: Memory per instance, no sharing between replicas

Pattern 2: Distributed Cache Layer

// Shared Redis cache
const redis = new Redis(process.env.REDIS_URL);

async function getCachedUser(userId) {
    const cached = await redis.get(`user:${userId}`);
    if (cached) return JSON.parse(cached);

    const user = await userService.getUser(userId);
    await redis.setex(`user:${userId}`, 3600, JSON.stringify(user));
    return user;
}

Pros: Shared across replicas, consistent view

Cons: Network latency, single point of failure if not clustered

Pattern 3: Cache-Aside with Events

// User Service publishes events
async function updateUser(userId, updates) {
    await db.updateUser(userId, updates);
    await cache.delete(`user:${userId}`);

    // Notify other services
    await eventBus.publish('user.updated', { userId, updates });
}

// Order Service subscribes
eventBus.subscribe('user.updated', async ({ userId }) => {
    // Invalidate any cached user data
    await cache.deletePattern(`orders:user:${userId}:*`);
});

Pros: Cross-service consistency, decoupled

Cons: Event infrastructure required, eventual consistency

Pattern 4: API Gateway Caching

// Kong/NGINX configuration
location /api/products {
    proxy_cache api_cache;
    proxy_cache_valid 200 5m;
    proxy_cache_key $request_uri$http_authorization;
    proxy_pass http://product-service;
}

Pros: Transparent to services, reduces service load

Cons: Limited cache logic, coarse invalidation

Pattern 5: Sidecar Caching

In Kubernetes, deploy a caching sidecar:

containers:
  - name: order-service
    image: order-service:latest
  - name: cache-sidecar
    image: cachee-sidecar:latest
    ports:
      - containerPort: 6380

Pros: Local cache access, consistent caching logic

Cons: Resource overhead per pod

Cross-Service Cache Coordination

When Service A caches data from Service B, you need coordination:

Option 1: TTL-Based Staleness

Accept that cached data may be stale for TTL duration. Simple but imprecise.

Option 2: Event-Driven Invalidation

Service B publishes change events; Service A subscribes and invalidates.

Option 3: Cache Versioning

Include version in cache keys; bump version on changes.

Handling Cache Failures

Cache failures shouldn't break your services:

async function getUserWithFallback(userId) {
    try {
        const cached = await cache.get(`user:${userId}`);
        if (cached) return cached;
    } catch (error) {
        // Cache unavailable - proceed to database
        logger.warn('Cache unavailable', { error });
    }

    // Fallback to database
    return await db.getUser(userId);
}

Monitoring Distributed Caches

Track these metrics across services:

• Hit rate per service: Identify which services benefit most
• Cross-service latency: Measure cache network overhead
• Invalidation lag: Time between change and cache update
• Memory usage: Prevent cache from consuming too much RAM

Conclusion

Effective microservices caching requires choosing the right pattern for each use case. Start with service-local caching for owned data, add distributed caching for shared data, and use events for cross-service coordination.

The key principle: each service should own its caching strategy while coordinating with others through well-defined events, not direct cache manipulation.