CODEWITHSUNDEEP
dependenciesmicroservices
touchaponk
touchaponk

Reputation: 404

Microservices API calls and dependency design

Are there any best practice on designing microservices service regarding API dependency (APIs that the service is calling to)?

For example if I have a "Order Management" (OM) service, obviously it will need to call "User Management" (UM) service since it will need to query user info (shipping address, email, etc) many times. If I let my OM calls UM all the time when it needs user info this will create lots of dependency on UM service.

As far as I understand services are supposed to be autonomous and as decoupled as possible - but now I got a OM service that will go down everytime UM service go down.

Upon searching on Google I found 3 alternatives:

  1. Use the event-based programming to replciate user data as soon as user data is created in UM module so it is always replicated into a table inside OM
  2. Use database's replciation mechanism to replicate data from UM onto OM database
  3. Copy user data into order object as nested json to eliminate dependency for order query and update (but I suppose initial order creation will still need to call UM)

Are there any best practices on the challenge here or are there any rules of thumb of deciding which design approach to take?

Upvotes: 4

Views: 1578

Answers (2)

Rénald
Rénald

Reputation: 1430

What you are talking about is a Bounded Context (BC), which is a DDD pattern. DDD fits well with SOA if the services boundaries correspond to BCs. BCs are meant to be autonomous parts of the system, that do not share any common business logic with each others. When designing your BC, you should not consider any idea regarding the database or other cross-cutting concerns. You should keep in mind making your code as specific as possible, then you should not be tempted to reuse code. Keep Web Services for parts of the system that are reusable, in regard to business. And prefer Eventual Consistency if you can (then you should be able to work with notifications rather than direct WS calls).

Regarding Eventual Consistency (if possible), I would choose the first option.

Upvotes: 3

Jose Martinez
Jose Martinez

Reputation: 12022

Microservices is a type of SOA (service orientated architecture). So if there is a service that does the required unit of work then why not call it versus getting involved with the back-end of a data-model that is not directly tied to the calling service. I would only go down the route of avoiding the UM service call if you hit some sort of performance or architectural issues. Even performance issues maybe addressed while still calling the UM service from the OM service.

As far as I understand services are supposed to be autonomous and as decoupled as possible - but now I got a OM service that will go down everytime UM service go down.

This argument can be used to show why you would use the UM service, so that the OM service does not have to get involved (coupled) with the inner working of the UM. If OM is coupled to UM's back-end and UM decides to change completely how it works, say going from relational DB to no-sql implementation, then that will lead to more work cause it will affect OM.

1.Use the event-based programming to replciate user data as soon as user data is created in UM module so it is always replicated into a table inside OM

My concern with this is that you are taking the implementation of the UM service and putting it into the OM service. Again I would only go down this route if you hit performance/arch issues and you can deal with having UM service logic coupled into the OM service.

2.Use database's replciation mechanism to replicate data from UM onto OM database

Coupling UM's backend to the OM.

3.Copy user data into order object as nested json to eliminate dependency for order query and update (but I suppose initial order creation will still need to call UM)

This is useful if it reduces the number of calls to UM. Bear in mind the cost of doing this, which might be the performance hit of carrying this extra information, which may or may not be an issue. The less the OM JSON is communicated and the more that the UM service is called, then the more ideal this solution is. But if UM service is only called once (say at the end of the order process) but the OM JSON passed around a lot, maybe this solution is more costly than its worth.

Upvotes: 2

Related Questions