I think you mean "distributed" instead of "highly concurrent".
The problem with making microservices highly coupled or even synchronous is that you end up with they call a distributed monolith, a system made by apps that are all dependent on each other to work, so instead of calling Object.function() locally and waiting for the result, you end up calling Class.remote_function() which sends a network call to another service and waits for the result.
The goal of microservices is to have separate and independent apps that can be scaled and deployed separately, without having to deploy other N services.
The same goes if they share a datastore (which might mean that a service can potentially break other services or services have to wait for another service to finish writing in the store).
So, if you shouldn't have them call each other directly and you shouldn't have them share a datastore, how do you pass messages between services? After all, from an abstract point of view, there's no difference between "Object.function()" and "send message from A to node B". It's all message passing. You do it asynchronously.
Asynchronicity though it's not a prerogative of a distributed set of services, you can do it with a regular monolotic application as well.
Nice! Thanks. I like your hypothesis about microservices, that match with mine. Yes, services should be decoupled as much as possible. But here comes another concept of 'single point of failure'.
Say in the e-commerce app I've described above, Order service is fully independent, can take orders and give the status of an order. Maybe the system is unable to take orders, but we need to show order status at least. How would we design that? Make two services? Then there's the store is getting shared among them.
There's always debate about microservices. But I really want to know the debates/ideas, it's important to choose how I am going to solve my problem based on other's experience in such similar cases. What would be your workaround at the current scenario? Just a primitive thought.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.