Can we completely avoid synchronous approach between microservices?

Question

1)If 2 microservices (say order and payment services) can connect asynchronously, then we can avoid using circuit/retry/throttle patterns, right?

2. I really dont understand why going synchrnous approach and using these patterns again? I mean using synchronous approach will have scalabale issues, right? Synchronous usecase should be only when some cache can be provided (say Order status can be asked via Synchronous and this can be cached as well)..

3. Am really not getting when really we have to chose synchronous/asynchronous between services... In internet says, avoid synchronous approach totally to avoid scalable issues and also saves lot money..

Answer 1

If your business requirements and existing tech setup allows, async communication is the way to go for the points you mentioned and for many others you didn't.

But you need to be aware of the caveats. Async is harder to implement then the sync one. It is also harder to debug and troubleshoot. You may also need some additional components to implement a reliably async communication. That means additional setup, configuration and maintenance etc.

Additionally in many occasions you can't implement this integration simply because of the business requirements. if for example the client expects a sync response from one your of backends you will have issues with this setup.

All in all after a decade of different shape and size of microservices project experience I would say async communication is not a silver bullet. Though I would try to go with it if possible that would not always be the case.

Answer 2

Few points to add to the other answer, why I would stress async communication is definitely not a silver bullet:

• Sync communication is actually lot less complicated than async. When we move from sync to async communication, we trade maintainability for scale, meaning if we do not need that scale then there is no point to trade maintainability of our system.
• Letting go of each of the problem areas in sync that was mentioned: circuit breakage, retry, throttle incurs cost in terms of either effort or price somewhere else. For e.g. we can ignore retry, if and only if we trust the availability of the system connecting the async communications (say a queue). Maintaining a queue with P999 availability, say, will either have maintenance effort or require a cloud managed service (like say as simple as an AWS SQS-SNS system) which will incur increased cost. Same applies for circuit or throttle.
• Another trade off in async, though debatable, is latency for scale. Sync essentially means you have a dedicated thread waiting for the answer to a question, meaning timeouts and SLAs tied to the same. If a service is unable to respond in 200ms it will probably throw a HTTP 500 triggering alarms above a threshold. The same expectation probably will not hold if an async response comes after 2 seconds instead of after 500ms. This is debatable since it can be implemented in both setups, it is more about how you expect a system to behave.

Basically it is ideal to take expected scale into account and verify the pros and cons of one vs the other before landing on a solution.