A General Cache Handling Mechanism for Static Business Data in Microservice Architecture

In distributed systems, especially microservice architectures, a common challenge is efficiently handling static business data that changes infrequently but requires high accuracy and real‑time access.

What is static data? It refers to data that rarely changes, such as vehicle model catalogs, basic user information, or vehicle details, which may be updated only monthly or upon user actions.

Why cache? Direct queries to relational databases are I/O intensive and cannot sustain high concurrency. In‑memory caching (e.g., KV stores) offers O(1) read complexity, dramatically improving throughput for read‑heavy scenarios.

General cache mechanism involves six core components:

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

Relational Database: persists business data (MySQL, SQLServer, Oracle, etc.).

Persistent Queue: decouples services and supports durable messaging (RabbitMQ, RocketMQ, Kafka).

Cache Processor: consumes queue messages and writes to cache.

Data Consistency Checker: periodically verifies and reconciles data between the relational DB and cache.

Cache Database (Redis): a persistent, horizontally scalable in‑memory store.

Two external definitions are also needed:

Data Producer: the source of static data (frontend app, web module, etc.).

Data Consumer: services that require the static data (e.g., alarm system).

Why a business service? It centralizes data operations, avoids redundancy across multiple front‑ends, and ensures consistent, high‑performance access.

Why not use in‑process cache? In‑process caches are limited by process memory and can cause cache avalanche when many instances restart or expire simultaneously.

Why Redis? Redis offers independent deployment, clustering, persistence, high read/write performance, and rich data structures, making it the de‑facto choice for distributed caching.

Why a queue? Queues decouple services, improve fault tolerance, and enable asynchronous processing (e.g., user registration → points awarding → email notification).

Why persistent queues? Persistence prevents data loss due to network glitches or crashes, though it may introduce duplicate handling and slightly lower throughput.

Why a consistency check program? It recovers from extreme failures (service crash before cache update, Redis failover) by reconciling stale cache entries with the source database.

Why not rely solely on cache expiration? Fixed TTLs create trade‑offs between data freshness and cache hit rate, and can still cause cache avalanche or stale reads under high load.

Summary The proposed mechanism uses a business service, persistent queue, Redis cache, and periodic consistency checks to provide high‑throughput, near‑real‑time access to static data while mitigating cache avalanche, ensuring durability, and supporting horizontal scaling.