I'm seeking an answer to a design question that I didn't find an answer to in any literature on this matter. Allow me to explain the use case, my solution to it and, ask for your opinion as a subject matter expert.
Use Case: We've several Microservices that all return some form of content from different business domains. We're using Spring Cloud Netflix, so a gateway service routes traffic to the content services. Some, if not all, of these services require data that is derived from the request, and is immutable. A trivial example is locale, although there are other proprietary information too.
Solution: I'm currently deriving the shared data in the gateway service and persisting as JSON in a NoSQL database with a unique key. Then I'm adding the key as a request header before routing the request. I've a shared library that the content services include at build time, and includes a Spring bean that reads the key from the request header, fetches the stored data using the key and initializes itself. This makes it possible for the content services to access the shared data (by simply injecting the previously mentioned bean) without knowing the underlying mechanism. If a content service invokes another one, it's responsible for adding the unique key as a request header.
Debate: The debate I've with my colleagues is that whether using a shared datastore for this purpose is appropriate. I contend that it is bad for a service to leak it's domain specific data to others, but the data in question isn't domain specific, so there's nothing wrong with having a shared database and passing the key around. The alternative would be to pass all the shared data around which I consider redundant.
What is your thought?
Aucun commentaire:
Enregistrer un commentaire