And for granular scalability, any microservice based architecture can
scale individual services independently to achieve the same right ? Am
I missing something here ?
Right, you aren't missing anything. Queues are just commonly coupled with microservices and benefit from the scalability perception.
Queues are not more scalable. Queues are more granularly scalable when coupled with a microservice architecture.
Additionally, queues are often used because they are a persistent store that can be used to process requests at a later time if the processing service is overloaded, broken, down, turned off, etc.
Let's take a sample workflow processing a loan application. It has two steps - convert the application to a standardized
Loan object and then qualify the application (i.e. determine whether the applicant is eligible). When these two processes are tightly-coupled in a monolith, we have to scale both processes simultaneously.
This is a waste of resources when only one of the two is a bottleneck. If we break the two processes out into their own microservices, we can scale them independently and connect them via queues.
Note that there is nothing special about a queue here - I can throw a load balancer in place of the queues OR just shoot over an API call to the second process and not await it. I would still be able to scale each microservice independently. However, queues are perceived to be more scalable, as they are often used in scalable infrastructure.
Queues can also provide a façade of scalability and high-availability to an end user. Let's say your loan application depends on a slow, unreliable third party. Without a queue, the user applying for the loan application will see a failure or infinite spinner. With a queue, you acknowledge that the application is received to the user, then process it from the queue once the third party is available.
The user gets an illusion that their request was processed instantaneously.
Tangent: To come back to what you already know - queues do provide a battle-tested way to ensure a message gets processed in ways that a load balancer or "simply shooting off an API message" do not (dead letter queues, visibility period, etc).