1 year, 2k views and no thumbs down. Pretty happy with that :D

Thanks Jose

Thanks, will do!

Glad it was helpful!

Glad it was helpful!

Glad you liked it!

Glad you enjoyed it!

Glad you liked it

Thanks for watching!

There is a configuration option in Lambda to either kill any processes that are running when you return, or to leave the lambda running until the JS event stack is empty. In general you should never return until all of your processes are completed. If you need to have something that runs a lot longer but you need to return an API response, it is best to invoke another process (fire EventBridge Event, add SQS event, call another lambda, trigger step function, etc) and then return your response. You handle that long running task' in another process.

If you want you can speed up youtube videos using the setting cog on the player. I tend to watch a lot of videos on 1.5 speed and pause it if I need to

You can have 1000 lambdas running at any one time. That doesn't mean 1000 QPS though. If a lambda only runs for 100ms, you could do 1000 requests and then another 1000 100ms later => 10K QPS. On the other side if your lambda takes 5 seconds to run, you could start 1000 at the same time, but have to wait 5s before starting the next 1000. This averages to 200 QPS.

You could ask for a lambda concurrency of 100K but I think AWS might say no- or at least as for a very good reason. Do you mean 100K requests/second or 100K concurrent request. These number are only the same if every request takes exactly 1s to run. Cost - assuming constant 100K requests/s for 0.3s per request 60s * 60m * 24h * 30d = 259 200 Million lambda invokes = $51,840 259.2 B invokes * 128mb * 0.3s * Lambda GB/s cost = $162,000.324 These are just estimate costs. Things that could change this 100k/s is probably the peak rate, what is the total invokes/month? how long would the lambda need to run for? What size memory does it need? If you're triggering with API Gateway then that's an extra cost. It sound like your use case might not be well suited to Serverless.

​@@CompleteCoding thank you so much for that and yes serverless might not be good for my use case but the thing is i expect to receive about 2million requests/day minimum ( for 100k users ) lets say 1m read and 1m write to databases if the 100k users are connected in the same time and that indeed is going to happen i'm sure that they won't do the same action that call the same lambda but i want to make sure that i don't have slow performance this is copy paste from AWS calculator i have increased it to 3 million requests / day and yes i won't need more than 128MB for memory Unit conversions Amount of memory allocated: 128 MB x 0.0009765625 GB in a MB = 0.125 GB Pricing calculations 90,000,000 requests x 1,000 ms x 0.001 ms to sec conversion factor = 90,000,000.00 total compute (seconds) 0.125 GB x 90,000,000.00 seconds = 11,250,000.00 total compute (GB-s) 11,250,000.00 GB-s x 0.0000166667 USD = 187.50 USD (monthly compute charges) 90,000,000 requests x 0.0000002 USD = 18.00 USD (monthly request charges) 187.50 USD + 18.00 USD = 205.50 USD Lambda costs - Without Free Tier (monthly): 205.50 USD

@@mohammedramadan3480 Those numbers look about right. The only real unknown at the moment is how long the Lambda will need to run to perform the task. If it runs less than 1s then it will be cheaper, if it runs longer then costing more

​@@CompleteCodingNice perspective, What would you suggest for; say I have 2000 users that open my app and I need 6000 concurrent execution (3lambdas x 2000users), but after that I do not these many concurrent requests until all app users open the app again at same time?

If you did have such highly spiky traffic then you have two choices. Always have enough capacity - this could be using lambda reserved capacity, fargate or ec2 (probably as ECS cluster). None of these scale down If you know that users open the app at a certain time (at half time in a football game) then you use fargate and program it to scale up just before the high spike in traffic. This idea of going from zero to 6000 requests is never going to be one that has a nice solution

But boring can be so interesting

I didn't find it boring