Designing Multi‑Level Cache Architecture for Microservices: From Browser to Redis

Today we discuss cache and how to design an effective multi‑level cache architecture in a microservice environment, covering three aspects: client‑side cache, application‑layer static resource cache, and service‑layer multi‑level cache.

Multi‑Level Cache Design in Microservices

Caching is a familiar technique for software engineers to boost performance. For read‑heavy scenarios like e‑commerce, data is stored in MySQL on disk while reads are served from an in‑memory NoSQL database such as Redis, which acts as the cache.

In distributed architectures, each layer has its own cache design, illustrated by the following multi‑level cache diagram.

The diagram shows four layers from top to bottom: client, application, service, and data.

Client‑Side Cache

In a browser, static resources such as images, CSS, JS, and fonts are cached. For example, Baidu controls the cache lifetime of its logo image via the HTTP Expires header, allowing the browser to serve the image from local disk until the specified expiration date, reducing bandwidth usage.

Application‑Layer Cache

Expires headers are set not in the browser but in the application layer, typically via CDN or Nginx configurations.

CDN (Content Delivery Network)

CDN distributes static resources across geographically dispersed nodes, reducing latency for users far from the origin server. Smart DNS directs users to the nearest CDN node, which caches files locally and serves them without contacting the origin server on subsequent requests.

Cloud providers such as Alibaba Cloud and Tencent Cloud offer CDN services with additional response‑header management, e.g., setting Cache‑Control to define cache duration.

Nginx Cache Management

Nginx is a high‑performance web server that also provides static resource caching. Adding the following configuration enables caching of static files and sets appropriate expiration times.

# Set cache directory
# levels=1:2 creates a two‑level directory structure for cached files
# keys_zone defines the cache name and memory usage (babytun-cache, 100m)
# inactive=7d removes files not accessed for 7 days
# max_size=20g limits the cache size to 20 GB
proxy_cache_path d:/nginx-cache levels=1:2 keys_zone=babytun-cache:100m inactive=7d max_size=20g;

# Define upstream server pool with weight for 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 on port 80
    listen 80;
    # Cache static resources (case‑insensitive regex)
    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 validity periods
        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, serving them directly without contacting the backend while the cache remains valid.

Service‑Layer Cache

Beyond CDN and Nginx, backend services also need caching for API and data objects. Caches can be in‑process (e.g., EhCache, Caffeine) or distributed (e.g., Redis).

In‑Process Cache

In‑process caches allocate memory within the application, offering low latency. Frameworks like Hibernate, MyBatis, and Spring MVC use such caches, with popular implementations including EhCache and Caffeine.

Distributed Cache Services

Distributed caches such as Redis provide a centralized in‑memory store for shared data. Multi‑level caching combines in‑process and Redis: if data is missing in EhCache, the application queries Redis; if still missing, it falls back to the database, then updates both caches.

Ensuring Cache Consistency

Multi‑level caches introduce consistency challenges. When a product price changes, the system must push update messages (e.g., via RocketMQ) to invalidate or refresh caches across instances.

Using a message queue, the service instance publishes a change event; other instances and Redis receive the event, delete stale entries, and write fresh data, maintaining consistency.

When to Adopt Multi‑Level Cache

Three scenarios suit multi‑level caching: (1) stable data such as postal codes; (2) bursty high‑concurrency events like flash sales; (3) data where eventual consistency is acceptable, allowing T+1 batch updates.

Conclusion

This article covered cache design across client, application, and service layers in microservice architectures, explaining browser Expires headers, CDN and Nginx static caching, and multi‑level service‑layer caching with consistency mechanisms.