Designing Data Redundancy and Decoupled Synchronization for a Supply‑Chain Microservice System

The author, Chen, describes a supply‑chain system composed of three core services—Product, Order, and Purchase—each with its own master data schema.

Initial requirements demanded order and purchase queries based on product attributes such as model, category, production year, and code. The first design followed strict microservice boundaries: the Order and Purchase services called the Product service to obtain matching product IDs and then used IN clauses to retrieve related records.

This approach quickly degraded performance as product volume grew, leading to slow IN queries, time‑outs in the Product service, and cascading failures in dependent services.

To address the bottleneck, the team introduced data redundancy by storing selected product fields directly in the Order and Purchase tables, eliminating the need to call the Product service at query time.

Two ways to keep the redundant data consistent were considered: (1) the Product service updates Order and Purchase directly after each change, and (2) the Product service publishes a message that the other services subscribe to and update their copies. The first method was rejected due to consistency and dependency problems.

The message‑driven approach was chosen because it keeps the Product service focused on its own logic, adds only a lightweight MQ publish, and allows retry mechanisms to handle update failures, preserving data consistency.

However, the redundancy model still required each dependent service to subscribe to many product‑related change events (category, batch, warranty type, etc.), leading to duplicated synchronization code and a proliferation of MQ topics.

To further decouple business logic, the team designed a real‑time data‑sync solution: product‑related tables (including categories and batch tables) are continuously replicated to the databases of Order and Purchase services, while those services query the replicated tables directly and never modify product data.

The architecture diagram (see first image) illustrates this flow, and a comparison of open‑source change‑data‑capture tools (Canal, Debezium, DataX, Databus, FlinkX, Bifrost) is presented. Bifrost was selected for its UI, simple architecture, active maintenance, and built‑in monitoring.

After deploying Bifrost, the system achieved stable product data synchronization, allowing developers of Order and Purchase services to focus solely on their core logic without worrying about product data consistency. The only remaining concern is Bifrost’s lack of clustering for high availability.

In conclusion, the decoupled synchronization architecture resolves inter‑service data dependency issues while improving performance and reliability.