Skip to content
loading...

re: Why a distributed system (highly concurrent) is mostly asynchronous? VIEW POST

FULL DISCUSSION
 

Correct me if I'm wrong, but I don't think your question is entirely correct. Concurrency simply means that a process can be split up into tiny calculations that can then be run in any orders without affecting the final result. So I suppose that the internal processes could be considered asynchronous. In the end it all depends on if you specifically call the entire process synchronously or asynchronously. So concurrency as a whole has nothing to do with being synchronous or asynchronous.

So the answer to your second question is yes, you can make this synchronous as a whole, but the internal calculations cannot be synchronous by definition. Otherwise it wouldn't be concurrent any more.

 

Sorry, I was meant to say concurrent network calls. Yes, the question seems a little vague in the first look but I think you got the idea. Can you suggest me to rewrite it properly?

And actually, by the internal process, I meant microservices. I.e. think of an e-commerce system, where the internal services can be order service, product service, auth service and the client-facing website which is served by a gateway. Should the connection among them be always asynchronous or can they be synchronous, which in common sense will take more time in the gateway and also will cause to lose concurrency, isn't it?

 

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.

code of conduct - report abuse