Architecture Patterns: API Gateway, Layers & Statelessness

Serverless API: API Gateway + Lambda

API Gateway handles routing/auth/rate-limiting for incoming HTTP requests, invoking a Lambda function per request — a full REST API with no continuously-running web server to manage. Costs are incurred only when actually handling requests.

Execution Role & Least Privilege

Every function needs an IAM execution role granting exactly the permissions it needs (read this S3 bucket, write that DynamoDB table) — not broad account access. Scoping tightly limits blast radius if a function is ever compromised.

Layers, Step Functions & DLQs

Layers share common code/dependencies across multiple functions without duplicating them per deployment package. Step Functions orchestrates a multi-step workflow across several Lambda functions (branching, retries, parallel steps) rather than cramming a whole process into one function. A dead letter queue captures events that repeatedly fail processing for later investigation, instead of silently discarding them — the same pattern RabbitMQ uses.

Statelessness

Don't rely on in-memory state surviving between invocations — a warm environment MIGHT retain it briefly, but a fresh one can spin up at any time (especially scaling up). Persist anything that must survive using an external store (database, S3), not incidental warm-environment memory.

When Lambda Fits

Good fits: image processing on upload, API handling, scheduled jobs, event-stream processing — event-driven, short, stateless, variable frequency. Poor fits: persistent connections, very long execution, extremely strict/consistent low latency with zero cold-start tolerance, sustained heavy CPU/memory — better served by a continuously-running server or container. Lambda@Edge extends this to CloudFront edge locations for latency-sensitive logic run close to the user, similar to Cloudflare Workers.