
AWS Lambda Is Not a Magic Reliability Wand - karl_p
https://medium.com/@karl.pickett/aws-lambda-is-not-a-magic-reliability-wand-91da728acba
======
astuyvenberg
Lambda may not be a magic reliability wand, you definitely still need to
manage downstream pressure. That said:

> The code creates a MySQL connection during each invocation.

This is not a correct implementation for Lambda.

You shouldn't recreate a connection on every invocation. Instead, create your
connection outside of your handler code. Then each invocation of a warm
container will re-use the same handler. (1)

This will help cut down on cold start time, as well as help manage running out
of connections.

You should limit your maximum number of concurrent invocations to be equal to
the limit of your database threadpool. This is all in their documentation, as
well as several blog posts. (2, 3, 4)

[1] [https://docs.aws.amazon.com/lambda/latest/dg/services-rds-
tu...](https://docs.aws.amazon.com/lambda/latest/dg/services-rds-
tutorial.html)

[2] [https://www.jeremydaly.com/reuse-database-connections-aws-
la...](https://www.jeremydaly.com/reuse-database-connections-aws-lambda/)

[3] [https://medium.com/faun/reusing-connections-lambda-
functions...](https://medium.com/faun/reusing-connections-lambda-functions-
poc-1eb8068fd1db)

~~~
karl_p
[https://aws.amazon.com/blogs/compute/using-amazon-rds-
proxy-...](https://aws.amazon.com/blogs/compute/using-amazon-rds-proxy-with-
aws-lambda/)

> Your function code is cleaner, simpler, and easier to maintain.

I don't think your post covers the nuances. "Not a correct implementation"? We
weren't trying for lowest latency, we were trying for highest reliability /
simplest code / easiest to test. How do you test that your reused connections
handle the "timed out right as next request comes in" case?

~~~
astuyvenberg
I mean not correct in the literal sense. It's not about reliability nor
simplicity nor testability - the code is wrong. It has a bug. The code is
written without understanding that lambda containers can be re-used, thus,
it's exhausting a finite resource unintentionally.

You handle the "timed out right as next request comes in" case by memoizing
the connection in a variable and checking if it's null in the handler. If it
is, re-establish the connection.

