2

My understanding is that separate data store per service is a best practice in microservices architecture. This Nginx article mentions that, but it goes on to advocate a Master Data Management system for ensuring consistency of data across disparate data stores. How can both coexist peacefully? It seems to me that each individual service would be competing with the MDM solution for "owning" the rights to create/update/master data.

I'd love to hear from anyone that has an MDM solution plus separate data store per service. What MDM tool(s) are you using? Doesn't each service "master" its own data - e.g., shouldn't Order data be written ONLY via the Order microservice? If the MDM solution detects a problem with regard to data consistency around Order data, does it instruct the Order service to reconcile it - or does this happen in the MDM tool?

Also, how do you stand up an MDM solution without introducing undesirable coupling between services and the MDM solution? Teams developing services should be able to change schema as needed, but an MDM solution would need to know the intimate details of schema and thus be tightly coupled right?

Improve this question
5
  • Typically Microservices are implying a stateless applications, while MDM would imply persistence.
    – A.Rashad
    Nov 8, 2018 at 22:00
  • 1
    Thanks for the comment, but as the Nginx article states, many microservices DO in fact persist data using a one data store per service pattern.
    – Andy
    Nov 8, 2018 at 22:03
  • I recall back when we implemented an MDM solution (for our monolithic applications) we nominated golden truth for each aspect, and ignored the rest.
    – A.Rashad
    Nov 8, 2018 at 22:14
  • 1
    It seems to me that each individual service would be competing with the MDM solution for "owning" the rights to create/update/master data. if they are not Master Data Service, they have no rights.
    – Laiv
    Nov 9, 2018 at 8:11
  • FYI the latest edition of the ThoughtWorks Technology Radar shows the "technique" of Master Data Management in the "Hold" category which ThoughtWorks defines as "Proceed with caution."
    – Andy
    Nov 29, 2018 at 22:26

1 Answer 1

Reset to default
3

Question: what is the benefit of implementing a microservice (uS) infrastructure plus having a huge MDM system on top/in parallel?

If the different uS do hold all relevant data and do own that data in the sense of being really responsible and the "master"-system for that data, then there is no point in having that data within a MDM software on top.

Example: service A is the only responsible system for data A and cares about distributing that data A to any system in need of A. Service A could be a uS with a RESTful HA abstraction of its data. Now: let´s say a user recognizes an error in data A within system B. In order to maintain the data consistency and source of truth, that user is not allowed to change data A in system B, but he needs to change it in service A because service A is the master for data A.

In such an architecture: why would you need a dedicated MDM? What do you think?

Improve this answer
2
  • 1
    Aren't you then asking the "user" to recognize the error and rectify it in the right place? The user, in your model, now has to do the navigation that the original poster suggested were to be done by the Master Data Management component.
    – BobDalgleish
    Dec 20, 2018 at 13:49
  • 2
    I've done a fair amount of research into this topic at this point and have come to the conclusion that MDM, despite what the Nginx article says, will not be a good fix for my organization. I accepted this as the answer because as I see it, either MDM is the master of data or you have each uS master its data. Having both seems like overkill. There may be opportunity for MDM to exist on the analytical side of the fence, and MDM may identify data consistency errors, but having MDM auto-fix those errors seems incorrect to me.
    – Andy
    Jan 4, 2019 at 14:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.