Decoupling Business Logic with Real‑Time Data Synchronization: Redundant Data and Bifrost Middleware in a Supply‑Chain Microservice Architecture

In a supply‑chain system consisting of product, sales‑order, and purchase services, the business required queries based on product attributes such as model, category, production year, and code.

The initial design followed strict microservice boundaries: the product service handled all product data, and order/purchase queries first called the product service to obtain matching product IDs and then used IN clauses to join with orders or purchases. As the product catalog grew, these queries became increasingly slow, the product service became a bottleneck, and time‑outs began to appear, causing failures in dependent services.

To address the latency, a data‑redundancy approach was introduced, storing selected product fields directly in the order and purchase tables. This eliminated the need to call the product service during queries, but raised the question of how to keep the redundant data consistent when product information changed.

Two synchronization strategies were considered:

When a product is updated, the product service calls the order and purchase services to update their redundant copies. This was rejected because it introduced consistency problems (failed updates would require roll‑backs) and created undesirable dependencies, turning the product service into an upstream caller of many downstream services.

When a product is updated, the product service publishes a message; order and purchase services subscribe to the message and update their copies independently. This approach avoids direct service‑to‑service calls and leverages message retry mechanisms to ensure eventual consistency.

While the message‑based approach solved the dependency issue, it introduced new challenges: numerous product‑related tables (categories, batch numbers, warranty types, etc.) required separate message types, leading to duplicated synchronization logic across services, a proliferation of MQ topics, and complex integration testing.

The final solution decouples business logic by continuously synchronizing product‑related tables (including auxiliary tables) to the databases of dependent services, keeping the schema unchanged. Dependent services query the synchronized tables via joins and are prohibited from modifying them, eliminating the need for each service to implement its own sync code.

The architecture diagram (see image) shows product data being streamed in real time to order and purchase databases, allowing queries without invoking the product service. This design resolves two major pain points: the product service no longer depends on other services, and dependent services no longer need to manage redundant data synchronization.

The trade‑off is increased storage in order and purchase databases, but a quantitative analysis shows that storing only the M product records (instead of N redundant copies per order) consumes far less space when N » M.

To implement the real‑time sync, a middleware meeting five criteria—real‑time, incremental, no custom business code, MySQL‑to‑MySQL support, and active community—was required. After evaluating Canal, Debezium, DataX, Databus, Flinkx, and Bifrost, Bifrost was selected for its user‑friendly UI, simple architecture, active maintenance, and built‑in monitoring/alerting.

After deployment, the synchronization remained stable, allowing developers to focus on core logic. The only remaining concern is Bifrost’s lack of clustering support, which limits high‑availability guarantees, though no outages have been observed so far.