Designing Multi-Level Cache Architecture in Microservice Environments

In microservice‑based applications, caching is a primary technique for improving performance. This guide walks through a comprehensive multi‑level cache design, from the client browser to the data layer, and discusses how to keep cached data consistent.

Multi‑Level Cache Design Overview

The architecture consists of four layers: client, application, service, and data. Each layer can host its own cache, forming a hierarchy that reduces latency and load on downstream systems.

Client‑Side Cache

Browsers cache static assets such as images, CSS, JavaScript, and fonts. Using HTTP Expires headers (e.g., the Baidu logo expires in 2031) allows browsers to serve resources from local disk without contacting the server, dramatically cutting bandwidth for high‑traffic web apps.

Application‑Layer Cache

Static resources are also cached at the edge via Content Delivery Networks (CDN) and at the web server level with Nginx. CDNs replicate content across geographically distributed nodes, using intelligent DNS to route users to the nearest node. Nginx can be configured to cache static files and set appropriate Cache‑Control directives.

Example Nginx configuration for static‑resource caching:

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

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;
    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;
        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;
    }
}

After adding this configuration, Nginx stores cached static files locally; subsequent requests are served directly from the cache until expiration.

Service‑Layer Cache

Beyond static assets, backend services benefit from two types of caches:

In‑process cache : memory inside the application (e.g., EhCache, Caffeine) that stores frequently accessed data with ultra‑low latency.

Distributed cache : external systems such as Redis that provide a shared cache for multiple service instances.

Combining both allows a “cache‑aside” pattern: the application first checks the in‑process cache, then Redis, and finally the database. Writes update both caches to keep them synchronized.

Ensuring Cache Consistency

Multi‑level caches introduce consistency challenges. A common solution is to publish data‑change events via a message queue (e.g., RocketMQ). When a service updates a record, it sends a message; other instances receive the event, invalidate stale entries, and repopulate the caches.

When to Adopt Multi‑Level Caching

Three scenarios are especially suited:

Data that changes rarely (e.g., postal codes, historical records) – reduces pressure on Redis and the database.

Sudden traffic spikes (e.g., flash sales, ticket booking) – in‑process caches absorb bursts, preventing Redis overload.

Data where eventual consistency is acceptable (e.g., user profile bios) – T+1 batch jobs can reconcile differences.

If the application’s load is modest, a single Redis cluster may suffice without the added complexity of multi‑level caching.

Conclusion

Effective caching in microservice architectures involves layering caches from the browser to the data store, configuring CDN and Nginx for static assets, leveraging both in‑process and distributed caches for dynamic data, and using message queues to maintain consistency. Properly applied, this approach dramatically improves response times and reduces backend load.