I'm implementing a low-cost architecture in AWS that I have an RDS database with Multi-AZ to handle failure and I have a website of sales. I implemented a Cloudwatch to monitor the use of the database and if is reaching the limit, it triggers a lambda to upgrade the instance type of the RDS to handle the new incomes requests in the RDS. But the problem is, even with the Multi-AZ, which has an new instance to handle requests while the main database is off when the upgrade is running there is a time that you can't connect into the database for like 2 ~ 3 minutes.
Reference -> https://medium.com/funambol-techblog/managing-auto-scaling-of-rds-on-aws-using-the-aws-cli-and-bash-9b1aa970ade3
(Even with a Multi-AZ RDS deployment, the failover of an RDS instance introduces DNS changes and up to 2–3 minutes of unavailability of the database.)
I didn't want to implement a high-cost architecture with cache or a new database, so I tried to implement an SQS to keep the requests that failed to connect with the database waiting 2~3 minutes until the upgrade finished.
But the problem is if Client A tries to buy product A, and the database is Down, it should go to the SQS to wait until the upgrade is finished. But if Client B tries to buy the same product and is quicker to reach the database, when Client A got out of the SQS it would not buy his product.
Is there any concurrency technique to solve this problem?