Deign pattern to correctly deduct credit balance in parallel HTTP requests

To keep it simple, let say user can purchase prepaid credits from my website. Then user can make HTTP requests to my API service. Each HTTP request will cost 1 credit. I also have transaction log the request (like ledger) in a table and calculate the new balance credit and update the value in another table.

My problem is when user have balance credit of 1 and starts making multiple HTTP requests (parallel) at same time, my authorization policy in my server will simply accept all their requests since they have 1 credit balance left over at the time of making that request. Is there any design pattern or any solution that i can implement to avoid this kind of race condition?

I have thought about some solutions such as implementing a queue system and database row locking. But this all seems convoluted and with little experience in this area i think many can go wrong.

Please suggest a solution, i also ready to fully rewrite if there is solid design pattern or solution that solve this issue.

Thanks in advance.