2

I don't think one can achieve full decoupling with micro-services. We might have a Microservice architecture in which they are fully dependent on each other.

Example

I have 2 services: an order service and an account service. My order service process order placements, dispatch and shipping. And my account service contains information about customer account.

For a customer to place an order, the order service needs to contact the account service for the customer to check if the customer has enough balance. In this way my order service is fully dependent on account service (I think management of dependencies is usually rarely talked about in Microservice architecture).

Question

I will be interested to know if theres any other way to achieve full decoupling of these scenarios.

Improve this question
2
  • you might find this video helpful youtu.be/CZ3wIuvmHeM your services typically need to interact with each other to provide some combined functionality. the challenge is now to deal with failures gracefully in that scenario. note that in that video (at 19:10) he says netfix uses client libraries for microservice to communicate with each other (they are coupled at code level!) not pure rest. Commented Dec 27, 2020 at 11:46
  • @simbo1905 thanks from the video. i could also see he mentioned alot about dependencies in their micro-service architecture which basically means most services still being coupled. however Netflix uses Hystrix which handles fault tolerance in RPCs. to avoid cascading effect when one dependent service happens to go down. in which you could achieve this behavior normally in your programming framework. at the end of the day what i can see is theirs no way you can achieve no coupling in micro-services in most scenarios. i would be willing if anyone can tell me if such exist Commented Dec 27, 2020 at 13:06

2 Answers 2

Reset to default
5

Short answer: No. You do not always need to achieve full decoupling.

Long answer: Yes, you should absolutely strive to decouple your services as much as possible, if you have a reason to do so. Most notably if they are developed by different teams, or scale differently, deployed elsewhere, etc.

...my account service contains information...

There's your problem, and it is a very common one. "Containing information" is not a task that can be decoupled from consumers of that information. You'll have to design differently. You'll need to create services for a specific business function, not technical ones.

If you need the customer "balance" to complete your business use-case, you might need to move the balance to the service that needs it. That way, you don't have to always ask for it and there is no coupling.

Of course, no coupling is not always feasible nor desirable. In short you should try to keep the type of couplings as high on this list as possible:

  1. No coupling at all. Obviously this is best.
  2. Coupling through the UI, like links and forms, embedding, etc. This still has no direct communication.
  3. Fire-and-forget messages. Communication strictly one way and because of that no influence on the logic. Can be used for lazy synchronization of information, triggering, etc.
  4. Request-response messages. These are the worst and are to be avoided if at all possible.

So there are at least 3 alternatives to request-response type dependencies off the top of my head.

Improve this answer
6
  • think about a scenario where "customer balance" information is needed across multiple service? would you rather "duplicate" this information across multiple services which will be a terrible idea?. i think micro services decoupling can be full achieved in scenarios like. fire and forget, event queues (e.g email notifications). services in which their systems need to be all active before you can complete a business workflow will always require dependencies. Commented Dec 27, 2020 at 12:19
  • 1
    I would look at each of those scenarios where the balance is needed and think about whether those need to be separate or not. If not, then bring them together and give them the information. If not, how many need to be separate? Next look at whether balance could be eventually consistent. If yes, maybe just duplicate it. If you do have a "business workflow" that need to be completed, unless there are any factors to the contrary, bring it into one service. Don't distribute parts of a single use-case unless you absolutely have to. Commented Dec 27, 2020 at 12:41
  • To add something, sometimes data is actually multiple things in different contexts even though it’s the same thing in our minds. For example user balance is only a number in a service handling a whole set of user data, but in a billing service it could be multiple rows in a database all containing transactions moving this user balance around. It’s rare to see pure and dumb duplication of data across different services. Commented Dec 27, 2020 at 13:23
  • 1
    from what i can see here. there is no way to avoid full decoupling with most micro service scenario. the more we try to achieve that the more problems we face with other factors. theirs basically no way to fully decouple a business work flow which are dependent on each-other. you can only implement fault tolerance mechanisms to avoid cascading errors when one service is down (like how Netflix architecture as based using Hystrix.) Commented Dec 27, 2020 at 13:53
  • Yes, there is no way to fully decouple things that need each other. That's why things that need each other should be preferably together. I'm sure if Netflix would not need different scaling for parts of their software they would have integrated them and would therefore not need hystrix. Commented Dec 27, 2020 at 14:06
0

No.

You cannot with what is known as "Microservices". But you can with "Microprocesses".

What's wrong with Microservices - RPC

In practice, Microservices are minimally:

  • Procedures that are Remotely Called
  • Principal gateways toward a resource (ie. Table)

Any RPC Service is there to be a standard way to guard against incorrect resource access. Therefore, they must be "called".

The most fundamental microservices are for "CRUD" { List, Add, Get, Delete }. This means that they are enforcing authorisation limits, but may also be enforcing other business-logic related requirements.

Next, there are Orchestration microservices. These coordinate more complex logic across multiple resources. One common example is joining data. Often these are best implemented where they can directly access tables in the one database, but purists don't like to bypass CRUD microservices.

How Microprocesses enable full decoupling - without RPC

see https://colossal.gitbook.io/microprocess/differences/compared-to-microservices (I am the author - it is currently a draft [2020-12-29])

A Microprocess is only the logic, and it can only trigger from a database. The database takes care of security. The client application talks SQL directly with the database (through a modern Database Web Gateway - similar but better than GraphQL).

Microprocess architecture decouples:

  • Business Logic
  • Authorisation
  • HTTP Access to Data
  • Caching

This means there are no dependencies. At most, a microprocess only has local Microdata dependencies (Input Data, Output Data).

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.