Designing a Universal Static Data Cache for Microservice Architectures

What Is Static Data

Static data refers to information that changes infrequently, such as vehicle model catalogs, basic user profiles, or vehicle details. Updates may occur monthly for model catalogs, while user and vehicle information changes only during registration or modification, making the data relatively stable.

These data also demand high accuracy and real‑time availability; loss, errors, or prolonged staleness are unacceptable. Whether data qualifies as static depends on business definitions and the frequency thresholds applied.

Why Caching Is Needed

In user‑oriented and vehicle‑connected services, model, user, and vehicle data are queried frequently. Storing such data in relational databases leads to low I/O efficiency and struggles under high concurrency. An in‑memory cache (e.g., a KV store) dramatically improves read throughput with O(1) access time.

Alternative techniques like read‑write splitting or sharding help overall I/O but do not address the specific need for rapid read‑only access to large static datasets.

General Caching Mechanism

The proposed universal mechanism consists of six core components:

Business Service : Provides CRUD APIs for static data (e.g., vehicle service).

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

Persistent Queue : Decouples services and guarantees durability (RabbitMQ, RocketMQ, Kafka).

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

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

Cache Database (Redis) : A persistent, clustered in‑memory store used as the primary cache.

Two external roles are also defined: the data producer (source of static data) and the data consumer (services that need the data, such as an alarm system).