CODEWITHSUNDEEP
microservices
macsj200
macsj200

Reputation: 149

Are cyclical dependencies between microservices an anti-pattern?

Say I have a user-accounts service and a profiles service. If the profiles service requires data from the user-accounts service for certain computations that means the profiles service depends on the user-accounts service.

Now, say additional functionality is being implemented for the user-accounts service. This functionality requires data from the profiles service.

This would create a cyclical dependency as each service depends on the other. Is this considered harmful?

What are some alternatives to introducing a cyclical dependency between microservices? Would it be best to add an additional service to serve as a broker?

Upvotes: 0

Views: 112

Answers (1)

Ryan.Bartsch
Ryan.Bartsch

Reputation: 4190

I would try to avoid this scenario. Personally I try to avoid coupling microservices altogether and rely more on orchestration and/or event choreography.

Here are some ways that you might be able to avoid it:

  1. Combine user-accounts and profiles as a single microservice. If they're closely related, perhaps you have your service granularity slightly wrong.
  2. Create a higher-level orchestration layer that orchestrates calls between user-accounts and profiles.
  3. Depending on your specific scenario, you might be able to choreograph events between user-accounts and profiles. One service might publish events, while the other service is subscribed to these events. You can use a message broker like RabbitMQ in this type of architecture.

There's no absolute right answer IMO - these are just some general guidelines - it really depends on your specific scenario...

Upvotes: 1

Related Questions