2

I have read in a DDD book that using message queues between communicating services can make the whole architecture more scalable, amazon's documentation mentions that queues provide granular scalability. I don't see how it is 'more' scalable than services communicating synchronously using http. I agree that it scales more gracefully, for eg., if we use the queue size as an indicator to grow and shrink the number of consumers if required.

But that doesn't mean that it is impossible to scale without queues right ? And for granular scalability, any microservice based architecture can scale individual services independently to achieve the same right ? Am I missing something here ?

Note: I'm only curious about the scalability side of this, I'm aware of other benefits of queues like better decoupling, availability. I agree that queues scale more gracefully but don't see why its impossible without them.

Improve this question
1
  • 2
    Your use of "impossible" could mean that you're thinking in a way that's too black & white. Even assuming that there's no hard limit in terms of what's theoretically possible, in practice, if something scales, as you've said, more gracefully, then you can scale it to a larger extent before you hit so much complexity that it becomes hard to control all of it (too resistant to change, too much knowledge for various teams to all share, too many interactions to keep track of, too many unpredictable circumstances to be robust against, too many factors that can degrade the design).
    – Filip Milovanović
    Apr 7, 2021 at 20:37

3 Answers 3

Reset to default
10

It's not that queues are more scalable, its the fact that two services communicating through queue means the communication is asynchronous. Asynchronous communication is far more scalable than synchronous communication, as it allows the writer (who enqueues messages into the queue) and the consumers (who dequeues the messages) to progress in their own rhythm.

Let's say you have a REST API service which is being called from your client side and perform some long running operation task.

If the communication was synchronous (the API service doesnt return a HTTP status code before it finishes the task), on high volumes of traffic your API service may crash as it will be too loaded or it will not finishes his task on time, which will eventually result in HTTP timeouts.

If the communication is asynchronous, your API service will only queue messages that will be processed by some background worker, and it will be able to return HTTP response message relatively quickly.

Improve this answer
1
  • 1
    There are ways around that besides queues. One is asynchronously dropping an API request to a service without waiting for a response. Another is hitting a load balancer.
    – VSO
    Sep 1, 2022 at 2:04
3

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.

enter image description here

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.

enter image description here

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).

Improve this answer
1
  • 1
    Well, OP was missing the word "granular", which they quoted and then completely ignored in the next sentence.
    – Useless
    Sep 2, 2022 at 13:32
0

Let's say we have an e-commerce app and we get 50000 requests to order service which means the same load to the database so we have to scale the DB at the same time. Currently, assume that we have not scaled DB yet and we don't have a message queue. So other services might hit the DB as well.

we have to change the same amount of load that hits the DB from order service. the way we change is the async processing which takes advantage of the fact that the load on our system does not remain constant throughout the day or week. If we can find a way to defer the processing of these requests, which are coming during the peak, we can store those requests, and later on when the load on our system is lesser, if we can at that time process these requests, we would save those requests to be rejected. Because if we get requests above the capacity we would reject them. so we would store requests in the message queue and then process them in order processing server. messaging queues can scale much higher than DBS

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.