Exposing DB table to other Microservice via a Library

Question

Consider I have 4 Services .

Account 
Order
Items
Customer

Now a External Partner Service calls all these services , by passing an External customer id ( EXT_CUST_ID) in the request.

Our platform has a Internal customer id (INT_CUST_ID) which can be found by querying EXT_CUST_ID inside EXT_ID_MAPPING table . As EXT_ID_MAPPING table would be common across all the services ,

Question 1 : Is it beneficial to maintain this EXT_ID_MAPPING table in each service ?

Question 2 : Or Exposing this table to all the microservices via Read only access a good design approach ? In such case can we create a client library that can be used by services to access this table ?

• amon: Microservices are typically used so that you can develop and deploy services independently. Introducing a client library goes against this goal: all services will have to use the same tech stack/language, and upon changes to the library (or database schema), all other services have to be re-deployed.
• Dev-vruper: Our focus is to understand if we can share this 1 table across all services ? And can we provide some kind of wrapper library that has Repository & Entity already defined , so that Services can use this library and implement their own logic to get data they need.

Answer 1

Accessing a table from other services will create a dependency on that table. That means that if a change to the table or database is made, any service that is using it will need to be modified in some way. That change needs to be coordinated across all the affected services. This is in direct conflict with the key goal of a microservices architecture. If by 'library' you mean a shared bit of code that queries the table directly, that doesn't help with this problem at all.

It's not clear to me why each of these services needs to look up the internal id. For example, you haven't explained why orders can't be associated with the external Id, or, why the internal Id can't be stored along with the external Id on orders. Regardless, if you need to lookup internal Ids by their external Id, the straightforward solution is to create a service that allows that lookup. The key difference from using a library is that you can modify the implementation details of the database without any change to that service API. This frees you from having to update a library on all the other services.

• Dev-vruper: Internal ID can be stored along with External Id in Orders service . But the problem arises when we want to update the Internal ID . If we store this mapping in all services , we will need to update the Internal ID in all services .
• JimmyJames: @Dev-vruper What is the need for the internal ID when working with Orders?
• Dev-vruper: Orders doesn't need internal ID , but to see a bigger picture and for the sake of giving an example I have included it in the list... sorry if it misguided .