Picture this. A fintech company processes thousands of transactions a day. Every single one of them has to pass through a fraud check before it goes through. That check calls out to a third party service, or runs some scoring logic that takes a second or two to complete. On a normal day, nobody notices.
Then a busy period hits. Maybe it is a payday, maybe it is a sale, maybe it is just an unusually active morning. Suddenly that same fraud check, the one that took a second or two, starts taking five seconds, then ten. Requests start queueing up behind it. New transactions cannot even get a response back. Support tickets start coming in. Someone on the team eventually says the dreaded sentence, the whole platform is down, and the actual cause is one check that was never supposed to be a bottleneck in the first place.
I have seen this pattern more than once, and it almost always comes from the same root cause. A fraud check, or any external dependency like it, was built to sit directly inside the request response cycle. If I walked into a fintech company and saw this happening, this is exactly how I would think through fixing it using NestJS.
What is actually happening under the hood
The problem usually looks something like this in code. A transaction comes in, and before anything else happens, the controller calls the fraud service and waits for a response before doing anything further.
