Designing a Universal Cache Strategy for Static Data in Microservices

What Is Static Data

Static data refers to information that changes infrequently or has a low change frequency, such as vehicle model libraries, basic user information, and basic vehicle information. These datasets require high accuracy and real‑time availability, and must not become stale or erroneous.

Why Cache Static Data

In user‑or vehicle‑connected services, model, user, and vehicle data are queried frequently. Storing them in relational databases yields low I/O efficiency under high concurrency. An in‑memory KV cache (e.g., Redis) provides O(1) read latency and greatly improves throughput.

Other techniques like read‑write splitting or sharding improve I/O but do not focus solely on read throughput, making them less suitable for pure read‑heavy static data scenarios.

General Cache Mechanism

The proposed universal mechanism consists of six core components:

Business Service : Exposes CRUD interfaces for static data (e.g., vehicle service).

Relational Database : Persists business data (SQL Server, MySQL, Oracle, etc.).

Persistent Queue : Independently deployed queue (RabbitMQ, RocketMQ, Kafka) that supports data persistence.

Cache Writer : Consumes messages from the queue and writes them to the cache.

Data Consistency Checker : Periodically verifies and reconciles data between the relational database and the cache.

Cache Store (Redis) : A persistent in‑memory database that is the industry standard for caching.

Two external roles are defined: the data producer (source of static data, e.g., front‑end app) and the data consumer (services that need the data, e.g., alarm system).

Why a Business Service?

Encapsulating data operations in a service avoids duplication, improves performance, and provides a single entry point for high‑concurrency queries across multiple clients (PC, mobile, etc.).

Why Not In‑Process Cache?

In‑process caches are limited by the host’s memory and can cause cache avalanche when many entries expire simultaneously, leading to a sudden load on the database.

Why Redis?

Redis can be deployed independently, supports clustering, persistence, high read/write performance, and a rich set of data structures, making it the preferred choice for a general cache.

Why a Queue?

A queue decouples services, allowing asynchronous cache updates and improving scalability. Persistent queues prevent data loss due to network glitches or crashes.

Why Persist the Queue?

Persistence guarantees that messages are not lost between the business service and the cache writer, at the cost of potential duplicate processing.

Why a Data Consistency Checker?

If a service crashes before writing to the cache or if Redis fails over, inconsistencies may arise. The checker periodically reconciles differences, ensuring near‑real‑time consistency.

Why Not Rely Solely on Cache Expiration?

Cache‑aside patterns avoid extra components but require careful TTL tuning to balance staleness and cache‑penetration risks. Dynamic TTL may be needed for bursty workloads.

Summary

The mechanism provides:

Business services that hide data source details and deliver high‑concurrency queries.

Queue‑driven cache updates that decouple write operations from cache writes.

Near‑real‑time cache freshness with occasional consistency checks for failure recovery.

Redis persistence to eliminate cache avalanche and support horizontal scaling.

Flexibility to drop components when the data volume or latency requirements are low.

Overall, this design offers a broadly applicable solution for caching static data in microservice architectures.