Hey Guys, The external REST service I am calling takes 35-50sec to respond. I am thinking of replacing API Gateway with an Application Load Balancer. I know it's not serverless and generates a monthly bill, but I can't find a way around 30sec timeout limit at APIG. I am not sure if anyone has tried this yet but I have a couple of questions: • Should I move all routes to ALB or just the ones which are getting timed out? Since I will be paying the ALB bill anyways does it make a difference? • Should I try decoupling my API into 2 parts? It's basically a booking service. Instead of sending a req and waiting for 35-55 sec, Should I submit a job and poll for status from UI like every 10 seconds? ◦ APIG calls lambda which pushes input to SQS and returns a polling ID ◦ SQS calls the consumer lambda, which calls external service, and writes data to DB against polling ID. ◦ Another APIG route takes polling ID and checks if the record is available in DB.

What is it that takes so long? Your decoupled approach is something I've used in the past where the computation required by the lambda just takes a long time. In my case i return early from the lambda with a presigned url to s3, then the frontend polls for a result using that url. In my case it was for a download of a large zip file from s3 so th signed URL method worked very well Another option could be setting up a web socket API

I am using kiwi APIs to create a flight booking service. Their save booking API (creates booking sessions that can be confirmed later upon payment) takes around 40 sec on average.

I see, out of your control then, I think your polling option could work, or, as a I say, a web socket API

@Mr.9715 Moving your setup to an ALB might get you around a 30sec timeout, but as you've correctly identified you still have a long wait for a response from the third party server. In your case I would use your decoupled approach with SQS and DB. It's more work, but will scale. Given your third party service calls are taking > 30 secs to return, I would also argue that they would have problems if you hit them with too many requests. So using a queue would allow you to decouple your users from the third party service and allow you to control the rate so you don't flood the service.

thanks @kierans777 @Ross Coundon, I am working on the implementation right now. lets see if it works.

You should definitely decouple for the above reasons mentioned but also because your frontend can lose connection in that time

Yeah just to add, CloudWatch Insight does something like this. Query against log groups can take up to 15min. You make a

startQuery

call and it will return u a token. And you can poll the query status with the token periodicly.