I am building a new application and was reading about micro-services architecture. The architecture itself makes lot of sense from a development, deployment and life cycle management point of view. However one issue that came up was with regards to how to handle master data.
For example, I have 2 apps - say Sales app and a Ticketing app. Assume that both of these apps are built as own micro-services. However both of these apps, when deployed (assuming that they are deployed separately say Sales uses MongoDB and Ticketing uses MariaDB), would need to have access to the same master data instances e.g. Accounts, Products. This would mean that there would be a owner app for a given master data entity (e.g. for Accounts it might be the Sales app) and an interested party (e.g. Ticketing app would need to have information about Accounts).
There are multiple ways in which this can be achieved: - Data replication from master to interested party - Synchronous read from interested party to master (sync dependency is not recommended by the micro-services architecture paradigm) - Own centralized repository
Also even within Accounts, there can be a core part which is common for both Sales and Ticketing (e.g. account name, address etc.). However some aspects of the Account might ONLY be relevant for Sales and others ONLY relevant for Ticketing.
Any thoughts / best-practices / opinions regarding any of the above mentioned options ?