I’m new to microservices architecture and would appreciate your insights on the issue below.
I’m working on an ERP project that includes Offer and Order services. While these services serve different purposes, the Order database schema inherit about 90% of its structure with the Offer database. This means that whenever the Offer schema is updated, developers need to manually apply those changes to the Order schema as well.
I’m concerned that this approach may lead to long-term maintenance issues and does not align well with best practices. However, I’m also unsure if I’m overreacting in strictly following the Database Per Service pattern in microservices.
Would you recommend a better approach to handle this scenario? Any advice would be greatly appreciated!
If you’re concerned that maintaining two nearly identical schemas across services can become a headache in the long run then strictly following the Database Per Service pattern is a good practice, but in cases like yours, some flexibility might be beneficial.
One approach is to extract the shared schema into a separate service, like a Shared Data Service, which both Offer and Order services can query. This reduces duplication while keeping ownership clear. Another option is event-driven synchronization, where the Offer service publishes changes that the Order service can consume later/asynchronously.
If the overlap is truly unavoidable, you might consider schema versioning tools or automation scripts to keep the structures in sync with minimal manual effort. But if the Offer and Order services evolve independently over time, keeping separate databases could be the better long-term solution.
It depends on how tightly coupled these services need to be. If Offer and Order are deeply interconnected, a monolithic database might not be a bad choice. But if your goal is scalability and independence, decoupling them via events or a shared service makes more sense.