Lambda

Lambda runs event-driven Node.js functions without managing servers. Triggers include API Gateway, SQS, S3 notifications, EventBridge, and schedules. Each invocation gets isolated memory, a timeout ceiling, and temporary `/tmp` storage.

Design handlers to be stateless: read/write durable state in DynamoDB, S3, or RDS via RDS Proxy. Cold starts affect latency-sensitive APIs; provisioned concurrency and smaller bundles help. IAM execution roles grant least privilege per function.

| Limit | Typical impact | |-------|----------------| | Timeout (max 15 min) | Long jobs need Step Functions or queues | | Payload size | Large uploads go through S3, not the handler | | Concurrency account limit | Traffic spikes need reserved concurrency planning |

On interviews: cold starts, idempotency with SQS, API Gateway versus Function URLs, VPC-attached Lambda trade-offs, and when Lambda is wrong for a steady high-RPS API.

Common pitfalls: monolithic handlers; secrets in environment variables without rotation; connecting directly to RDS without pooling; ignoring partial batch failures on SQS triggers.

The trade-off is zero server ops and pay-per-use billing versus latency variance, duration limits, and harder local debugging.

Checklist:

• Keep handlers small, idempotent, and fast.
• Externalize state and use S3 for large payloads.
• Tune memory (CPU scales with it) and timeout deliberately.
• Grant minimal IAM permissions per function.