How does one service get the data from another service? I will give few examples:
1) Let's say we have two services which need to share the data: User Service and Order Service. Order Service pretty much will want to get some data User Service's database has like address, bonus points to cut the price, but all Order Service receives about a user is its userId, it doesn't have a direct access to the User DB.
2) An app has a user balance system with some internal coins used as base currency. The app provides different kind of services to buy which user can spend those internal coins for. The service responsible for fulfilling user's request should be somehow able to tell User Service or Balance Service (if it was decided to split balance from users to a different service) to reduce its balance depending on how much it costed or check the balance and then return a error if it's insufficient.
3) An app from #2 situation doesn't have predetermined price anymore, tasks got so complicated that now we need to run Analyze Service and now the task will go to that service to determinate the price of a task, what service should handle the task and only then the service which is able to fulfill user's request will do it.
So, I will give my thoughts about these after reading numerous articles about microservice architecture:
1) I see few ways to do it:
- direct synchronous HTTP request from one service to another to get the necessary data (slow, most importantly services are now coupled and I loose benefits of microservice architecture)
- client app has all necessary data in its global store (if it's a SPA app e.g.) and will just send them in the request (but we still need a mean to check if the data we got is valid…)
- saving necessary data in JWT (weird..?)
2) I guess here is a good example where message brokers come in handy. I could send a message about the task being done with its price and userId to User Service or Balance Service and callback will reduce user's balance.
3) Message broker again. Analyze Service sends a message, bound performing task service will start doing a task after analyze is finished, which task service will do that depends on the queue Analyze Service will send a message in.
I'm not sure about any of solutions here so here is my question. What are common ways to deal with those kind of problems?
Best Answer
Service dependencies (and losing track thereof) are not uncommon with a microservice architecture. It's also expected that services have local data and this data can be keyed with a primary ID from another service. For example, some services are going to have some data attached to a user ID like you observed.
You should look at whether or not you have drawn your domain boundaries correctly and where they are over- or undersized (or need to be co-located in the same service)
You are correct that it's not good to have the knowledge how to get a particular object from another service in a service. In the case of a user service, you might have to accept that such a service will likely be needed as the need for user data might be frequent. In this case, you might want to create a layer or directed graph model (everyone may use the user service, user service may not use order service...)
There is also the orchestrator model. In that model, the application or an orchestrator service pulls all the needed data together and then hands if off for processing. So you would read from product, user, bonus-point etc. and then pass all of that into order service as data. This reduces the number of locations where the knowledge how to retrieve this data exists.
Side effects (like crediting bonus points) benefit from an asynchronous message passing mechanism. Crediting bonus points does not block order processing and order processing does not need to wait for bonus points to be credited. As long as bonus points are credited eventually, you are fine. The message passing subsystem can buffer messages if that service is down and you again remove the knowledge where that service is located and how it operates from the caller.