Do you always need to achieve full decoupling in Microservices?

Question

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.

Answer 1

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.

Answer 2

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).