Designing Multi‑Level Cache Architecture for Microservice Applications

In a microservice architecture, caching is essential for performance, and a multi‑level cache design can be divided into three parts: client‑side browser cache, application‑layer static resource cache, and service‑layer multi‑level cache.

The article first introduces the concept of multi‑level caching, using a typical e‑commerce scenario where MySQL stores persistent data while Redis provides fast, in‑memory reads for the majority of "read‑heavy, write‑light" operations.

A four‑layer cache diagram is presented, consisting of the client, application, service, and data layers.

On the client side, browsers cache static assets such as images, CSS, JS, and fonts, often controlled by the HTTP Expires header; the example of Baidu's logo illustrates how a far‑future expiration reduces repeated network requests.

At the application layer, static resources are cached via CDNs and Nginx. CDNs distribute content geographically using smart DNS, while Nginx can cache and compress static files locally. The article shows the typical CDN request flow and explains how CDN providers add extra response headers like Cache‑Control for fine‑grained control.

For Nginx cache management, the following configuration snippet can be added to nginx.conf to enable static‑resource caching and load‑balancing:

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

In the service layer, caches are categorized as in‑process caches (e.g., EhCache, Caffeine) and distributed caches (e.g., Redis). Combining both allows a hierarchy where the application first checks the local cache, then Redis, and finally the database, reducing latency and network traffic.

Cache consistency challenges arise with multi‑level caches; the article recommends using a message queue such as RocketMQ to broadcast data‑change events, ensuring all instances invalidate or update their caches promptly.

Three scenarios where multi‑level caching is beneficial are identified: stable data (e.g., postal codes), extreme burst traffic (e.g., flash sales), and cases where eventual consistency is acceptable (e.g., non‑critical profile updates).

The conclusion reiterates the importance of tailoring cache strategies to business characteristics and suggests that for modest traffic, a single Redis cluster may suffice, while high‑scale systems should adopt the full multi‑level approach.