Hi @shanmuganand,
You are on the right track. Asynchronous messaging has its advantages like you mentioned but they don’t fulfill requirements for all usecases. In most usecases, your applications can have deferred execution and tolerate eventual consistency so that as soon as an event is fired, downstream applications can process and store that event at their own pace and be consistent eventually.
However, like you mentioned, there are some usecases such as payment authorization where you need instant validation (synchronous reply) that the payment was processed. It is not acceptable for your system to eventually process the authorization at some later time. It has to be processed synchronously before any downstream processes such as auditing, logging, or analytics can be kicked off. In such usecases, you have to use synchronous messaging.
Practically, your system will be a hybrid of RESTful synchronous communication and asynchronous communication. With Solace PubSub+ event broker, you can use REST for request/reply messaging and use pub/sub messaging for asynchronous communication. Here is an example of what that hybrid architecture would look like:
And here is a blog post I wrote about how that works.
Additionally, Sumeet Puri from Solace, presented (video) this exact usecase, at API Days Conference in Singapore, of payment authorization and using both sync and async messaging via Solace. I highly recommend checking it out.
I would be curious to hear what you are working on and how we can collaborate further. Payments is a very trendy usecase these days with a lot of regulators around the world working on implementing real-time gross settlements (RTGS) systems.
Hope this helped,
Himanshu