Hey, everyone.
And welcome back.
Now, in today's video, we are going to discuss about the role of message queues in the database transactions.
So let's go ahead and understand this with a use case.
So let's assume that you have a single database that is hosted on RDF.
Now, due to an ongoing sales promotion, the number of right transaction that has been happening in
the database recently has reached ten times the normal load.
So you have great number of right transactions that are happening now since you have a single database
that is present and there is a high load, many of the requests are failing regularly.
And there is one more important requirement here is that the new sale promotions that are ongoing because
of which there is 20 times the normal load, these sales promotions are scheduled every alternate month.
So these are not ongoing 24 seven throughout the month.
It is occurring every alternate month.
Now, based on this specific use case, let's go ahead and look into what is the solution that you can
implement.
Now, one of the simplest solution that one might assume here is that you can directly increase the
size of the database and also increase the number of provision IOPS so that it can handle the 20 times
higher load that is currently ongoing due to sales promotion, although this would work, but there
are certain limitations here.
First limitation is that there will be a downtime, so if you want to vertically scale this database,
you will have to shut down resize and then start the database again.
So this is one specific challenge.
Second challenge is increased cost.
For example, let's say that you have now scaled the database earlier Database had two GB RAM, now
your database has 16 GB of RAM and things are working perfectly well.
But what happens after the sale promotion has completed?
Your 16 GB database will be running all the time and that will increase your cost significantly.
All right.
So this is one of the architecture which organizations generally avoid going to primarily because of
these challenges.
So in order to overcome this, there is a better approach where a message queue is used.
So in this type of architecture, what happens is that instead of messages being directly inserted into
the database, they are now inserted as part of the ASCS queue and EC.
Two instances will pull the message from the queue and they will be inserting it to the database depending
upon the load.
So let's say that the database is already going through a very high load.
Then the messages can stay in the US queue for a minute or two for an example, and when the database
load increases the set of EC, two instances can pull the message and insert the data back to the database.
And this type of architecture you will see in many of the organizations.
Now, one thing to note is that in such kind of architecture, there will be a little time delay between
the message that have been sent by the client and the message that is inserted to the database.
So there will be a little time delay.
But for most of the use cases this time, delay does not really matter.
If you have changed your profile name in a specific forum and if that profile name gets updated, let's
say after 2 to 3 minutes, it does not really matter and so on.
So there are many of the use cases where it does not matter.
But for use cases where time delay is not acceptable, then this type of architecture is something that
you can avoid.
So again, in exams, depending upon the use case that they give, you can go ahead and select the appropriate
answer.
So with this will conclude today's video.