Designing Multi‑Level Cache Architecture for Microservice Applications

Multi‑Level Cache Design in Microservice Architecture

Caching is a fundamental technique for improving performance in modern software systems. In a typical e‑commerce scenario where reads far outnumber writes, data is stored persistently in MySQL while the majority of read requests are served from an in‑memory store such as Redis.

Client‑Side Cache

Browsers cache static assets (images, CSS, JavaScript, fonts) using HTTP response headers like Expires. When the cached resource is still valid, the browser serves it from local disk, eliminating network round‑trips and reducing bandwidth consumption.

Application‑Layer Cache

CDN (Content Delivery Network)

CDNs replicate static files to edge nodes close to users, using intelligent DNS to route requests to the nearest node. Cached files are served directly from the edge, dramatically lowering latency and offloading origin servers.

Nginx Cache

Nginx can act as a reverse proxy and cache static resources locally. The following configuration enables directory‑based cache storage, defines cache zones, and sets expiration policies for different HTTP status codes.

# Set cache directory and parameters
proxy_cache_path d:/nginx-cache levels=1:2 keys_zone=babytun-cache:100m inactive=7d max_size=20g;

# Backend server pool with weight‑based load balancing
upstream xmall {
    server 192.168.31.181 weight=5 max_fails=1 fail_timeout=3s;
    server 192.168.31.182 weight=2;
    server 192.168.31.183 weight=1;
    server 192.168.31.184 weight=2;
}

server {
    listen 80;
    # Cache static resources (gif, jpg, css, png, js, woff, html)
    location ~* \.(gif|jpg|css|png|js|woff|html)(.*) {
        proxy_pass http://xmall;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_cache xmall-cache;
        # Cache 200/302 responses for 24h, 301 for 5d, others for 5m
        proxy_cache_valid 200 302 24h;
        proxy_cache_valid 301 5d;
        proxy_cache_valid any 5m;
        expires 90d;
    }

    location / {
        proxy_pass http://xmall;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Service‑Layer Cache

Backend services can use two levels of cache:

In‑Process Cache

Local memory caches such as EhCache or Caffeine store frequently accessed data within the JVM, providing nanosecond‑level latency.

Distributed Cache

Redis clusters provide a shared, high‑throughput cache for data that must be consistent across multiple service instances.

A typical multi‑level strategy first checks the in‑process cache, then the Redis cache, and finally falls back to the database. Successful reads update both caches to keep them warm.

Ensuring Cache Consistency

When data changes, a message queue (e.g., RocketMQ) broadcasts invalidation or update events to all service instances, which then purge stale entries and repopulate caches, achieving eventual consistency.

When to Adopt Multi‑Level Caching

Three scenarios benefit most from this approach:

Stable reference data (e.g., postal codes) that rarely changes.

Extreme burst traffic (e.g., flash sales, ticketing spikes) where a local cache can absorb the surge.

Data that tolerates temporary inconsistency, allowing asynchronous refreshes.

If your application’s traffic is modest, a single Redis layer may suffice; otherwise, combine in‑process and distributed caches to balance performance and reliability.

Conclusion

The article covered cache design from the browser to the service layer, explaining how Expires headers, CDN, Nginx, and Redis work together in a microservice architecture, and highlighted consistency challenges and practical use‑cases for multi‑level caching.