Microservices API Requests and Dependency Design
Is there any best practice in developing microservices services regarding API dependencies (APIs that the service calls)?
For example, if I have an Order Management (OM) service, it will obviously need to call the User Management (UM) service, as it will ask for user information (shipping address, email address, etc.) many times, If I let my OM call UM all the time when it needs user information, it creates a greater dependency on the Unified Messaging service.
As far as I understand, the services should be self-contained and as decoupled as possible, but now I've got an OM service that will go down every time the Unified Messaging service is running.
While searching on Google, I found 3 alternatives:
- Use event-driven programming to exchange user data as soon as user data is created in the Unified Messaging module, so it is always replicated to a table within the OM
- Use the database replication engine to replicate data from Unified Messaging to the OM database.
- Copying custom data to the order object as a nested json to exclude dependencies for requesting and updating the order (but my guess is that you still need to call UM to create the initial order)
Are there any guidelines for the problem here, or are there any empirical solutions on which design approach to take?
source to share
Microservices are a type of SOA (Service Oriented Architecture). So if there is a service that does the required unit of work, then why not name it or tie it to the end of a data model that is not directly related to the calling service. I would only go the route of avoiding calling the Unified Messaging service if you are running into any kind of work or architectural issues. Even performance issues can be resolved by simultaneously invoking the Unified Messaging service from the OM service.
As far as I understand, the services should be self-contained and as decoupled as possible, but now I've got an OM service that will go down every time the Unified Messaging service is running.
You can use this argument to show why you will be using the Unified Messaging service so that the OM service does not have to join (tie into) the inner workings of Unified Messaging. If the OM is connected to a UM server, and the UM decides to completely change how it works, say moving from a relational DB to a non-sql implementation, then it will lead to more work as it will affect the OM.
1. Use event-driven programming to exchange user data as soon as user data is created in the Unified Messaging module, so it is always replicated to a table within OM
My concern with this is that you are implementing the Unified Messaging service and pushing it into the OM service. Again, I would only go this route if you are experiencing performance / architecture issues and you may be dealing with having Unified Messaging Service Logic in OM.
2. Use the database replication mechanism to replicate data from Unified Messaging to the OM database
Linking UM backend with OM.
3.Copy custom data to the order object as a nested json to exclude the dependency for requesting and updating the order (but I assume that you still need to call UM to create the initial order)
This is useful if it reduces the number of calls to the UM. Be aware of the cost of doing this, which may be due to the performance of this additional information, which may or may not be an issue. The less OM JSON is transferred and the more the name of the Unified Messaging service is, the more ideal this solution is. But if the UM service is only called once (say, at the end of the ordering process), but OM JSON has gone around a lot, it might be more expensive than the cost.
source to share
What you are talking about is a bounded context (BC) which is a DDD pattern. DDD is good for SOA if service boundaries are BC. Bookmakers should be autonomous parts of the system that do not share common business logic with each other. When designing your aircraft, you should not consider any idea of a database or other cross-cutting issues. You should keep in mind that your code is as specific as possible, then you shouldn't be tempted to reuse code. Store web services for parts of the system that can be reused for business. And, if you prefer, prefer Eventual Consistency (then you can work with notifications rather than direct WS calls).
As for the possible sequence (if possible), I would choose the first option.
source to share