How to Solve Microservice Data Dependency with Real‑Time Sync and Bifrost

Scenario

In a supply‑chain system there are three microservices—Product, Order, and Purchase—each with its own master data structure.

The two main requirements are to locate orders and purchase orders by product model, category, production year, or code.

Initially the design kept product responsibilities strictly within the Product service. Queries therefore first called the Product service to obtain matching product IDs and then used IN statements in Order or Purchase services.

This approach quickly showed problems as product volume grew: query performance degraded, the Product service became a bottleneck, and time‑outs caused downstream failures.

Data Redundancy Solution

Data redundancy stores selected product fields directly in Order and Purchase records, eliminating the need to call the Product service for each query.

Two ways to keep redundant data consistent were considered:

Update Order and Purchase services synchronously after each product update.

Publish a message on product change; Order and Purchase services subscribe and update their redundant data independently.

The first method was rejected due to consistency and dependency issues, leaving the message‑based approach as the preferred solution.

Decoupled Business‑Logic Data Sync Design

The final design synchronizes product‑related tables (e.g., category, batch, warranty) in real time to the databases of dependent services, keeping the schema unchanged and prohibiting Order/Purchase services from modifying product tables.

Thus, queries can join the synchronized product tables directly without invoking the Product service.

The advantages are:

Product service no longer depends on other services.

Order and Purchase services are insulated from redundant‑data sync failures.

The trade‑off is increased storage in Order and Purchase databases.

Choosing a Real‑Time Sync Middleware

Requirements: real‑time, incremental sync, no business‑logic code, MySQL‑to‑MySQL support, active community.

After comparing Canal, Debezium, DataX, Databus, Flinkx, and Bifrost, Bifrost was selected for its user‑friendly UI, simple architecture, active maintenance, and built‑in monitoring.

Production Results

After deployment, product data synchronization became stable; developers of the Product service focus solely on product logic, while Order and Purchase developers simply add join clauses in queries, achieving a win‑win situation.

The only concern is Bifrost’s lack of clustering, which limits high‑availability, though no outages have occurred so far.

Conclusion

The article discusses microservice data dependency issues, presents a decoupled real‑time synchronization solution, and recommends Bifrost as an effective middleware, while acknowledging potential limitations and inviting further discussion.