General Cache Handling Mechanism for Static Business Data in Microservice Architecture

In distributed systems, especially the popular microservice architecture, this article attempts to summarize a universal cache handling mechanism for static business data, clarifying key problems and exploring a common solution based on practical development experience.

What Is Static Data

Static data refers to data that changes infrequently or has a low change frequency, such as a vehicle model catalog, basic user information, or basic vehicle information.

For example, a vehicle model catalog may be updated once a month, while user and vehicle basic information changes only when users register or modify their profiles, which also occurs relatively rarely.

Another characteristic of this type of data is that it requires high accuracy and real‑time availability; loss, errors, or prolonged staleness are unacceptable.

Why Caching Is Needed

In user‑oriented or vehicle‑networking scenarios, vehicle models, user basics, and vehicle basics are queried frequently and often need to be associated with other data.

The purpose of caching here is to improve query efficiency. Static data is usually stored in relational databases, whose I/O performance is generally low and struggles under high concurrency.

Using a memory cache dramatically increases read throughput; key‑value caches typically have O(1) time complexity. The cache discussed is an in‑memory cache.

Besides caching, other techniques such as read/write splitting or sharding can improve I/O, but they aim to boost both read and write performance and are less effective when the sole goal is to increase read throughput under limited resources.

General Cache Mechanism

The following diagram illustrates the proposed universal mechanism:

The mechanism involves six core components for a specific business:

Business Service: Provides an API for operating a certain type of business data, e.g., a vehicle service offering CRUD operations for vehicle basic information.

Relational Database: Persists business data using tables such as SQL Server, MySQL, Oracle, etc.

Persistent Queue: An independently deployed queue program that supports data persistence, e.g., RabbitMQ, RocketMQ, Kafka.

Cache Processing Program: Consumes data from the queue and writes it into the cache.

Data Consistency Check Program: Verifies whether the cache and relational database are consistent; if not, it updates the cache from the database.

Cache Database (Redis): A persistent cache database; Redis is chosen as the industry‑standard solution.

Two external definitions are also needed:

Data Producer: The source of static business data, such as a front‑end app or a web module.

Data Consumer: Services or systems that need the static data, e.g., an alarm system that requires user information linked to a vehicle.

Why a Business Service Is Needed?

In a microservice architecture, services are inevitable. A business service centralizes data operations, providing a unified interface for CRUD actions on both the relational and cache databases, reducing code duplication, improving performance, and easing consistency control.

Without a service, each client would need to implement its own data handling logic, leading to redundancy, potential inconsistency, and difficulty in managing changes.

Why Not Use In‑Process Cache?

Many languages support in‑process caching via static variables or libraries, offering the fastest read speed. However, two major issues arise:

Cache Size Limitation: The cache size is bounded by the process’s available memory, and multiple services sharing a machine can cause resource contention.

Cache Avalanche: Simultaneous expiration or process restarts can cause massive cache misses, overwhelming the relational database and potentially causing a crash.

Why Redis?

Redis solves the above problems by being independently deployable (supporting clustering and easy memory scaling) and by offering data persistence, allowing rapid recovery after a restart.

Redis also provides excellent read/write performance, a rich set of data structures, and straightforward horizontal scaling, making it the preferred general‑purpose cache.

Why a Queue Is Needed?

The queue decouples the business service from cache updates. Although the service could update the cache directly after a database write, using a queue (e.g., RabbitMQ) isolates the two concerns, improves fault tolerance, and aligns with common microservice practices such as the Actor model.

For example, when a new user registers and needs points and a welcome email, handling all steps synchronously would increase latency and risk of failure. By publishing registration events to separate queues for points and notifications, each downstream module processes its task independently, improving scalability and resilience.

Why the Queue Must Be Persistent?

Persistence prevents data loss caused by network glitches or crashes during the flow from business service → queue → cache processor. It requires acknowledgment on send, durable storage in the queue, and acknowledgment on receive, though this may introduce duplicate messages and slightly lower throughput.

RabbitMQ is recommended for its balanced performance and reliability, sufficient for the relatively low update frequency of static data.

Why a Data Consistency Check Program?

If the business service crashes after writing to the relational database but before publishing to the queue, the cache may become stale. Additionally, Redis failover can leave replicas out of sync. A periodic consistency checker compares the database and cache, updating stale cache entries to ensure near‑real‑time accuracy.

The checker should operate on incremental changes (e.g., since the last run) to avoid excessive database load.

Is a Consistency Checker Sufficient?

For some data, such as a vehicle model catalog, periodic synchronization may be enough. However, for data like newly registered users or vehicles, consumers often require immediate access, making real‑time or near‑real‑time updates preferable.

Why Not Use Cache Expiration?

Cache‑aside patterns (read‑through with TTL) are common: query Redis first, fall back to the database on miss, then write back to Redis. The challenge lies in choosing an appropriate TTL—short TTL reduces staleness but increases cache miss and potential avalanche; long TTL improves cache hit rate but may violate the high‑accuracy, low‑latency requirements of static data.

Dynamic TTL mechanisms can balance these trade‑offs based on traffic patterns.

Summary

Encapsulate data operations within a business service, abstracting both relational and cache databases from consumers.

Use a persistent queue to decouple cache updates from business services, allowing asynchronous, reliable propagation of changes.

In most cases, queue‑driven cache updates provide real‑time performance comparable to direct updates while improving modularity.

A periodic consistency check program remedies extreme failure scenarios, quickly reconciling cache and database.

Consumers can query Redis for high‑concurrency, near‑real‑time access to static data; missing entries are fetched from the database without cache penetration.

The mechanism eliminates cache avalanche through persistence, supports horizontal scaling, and offers a broadly applicable solution for static business data.

For simple, low‑traffic static data (e.g., a nationwide restriction list), an in‑process cache may suffice, avoiding the added complexity of queues and consistency checks.

Implementing this architecture introduces additional development and maintenance overhead; teams must evaluate the necessity based on data volume, access patterns, and operational resources.

Postscript

Redis Coupling Issue: Direct access to Redis from business services makes full transparency difficult; an AOP approach could standardize data models across relational and Redis stores.

Cache data is near‑real‑time; for strict consistency, a fallback to direct database queries should be provided.

To avoid direct Redis dependence, OpenResty could be used for transparent resource access, though this is beyond the article’s scope.

Service Availability: The article does not cover high‑availability; each service should be deployed in multiple instances with load balancing or active‑standby setups to ensure continuity.

Written quickly, some points may be biased; feedback is welcome.