What happens when AWS Lambda reaches its concurrency limit?

For synchronous invocations (API Gateway → Lambda), additional requests receive a 429 TooManyRequestsException, which API Gateway translates to a 502 Bad Gateway for the client. For asynchronous invocations (S3 events, SNS, etc.), Lambda retries the event twice with delays, then sends it to a dead-letter queue if configured, or discards it. The default account-level limit is 1,000 concurrent executions per region, which is shared across all functions. Use reserved concurrency to guarantee capacity for critical functions and cap non-critical ones.

When should I use SQS as a buffer between API Gateway and Lambda?

Use SQS buffering for any write operation or processing task where: (1) the processing takes more than a few seconds, (2) the downstream resource (database, third-party API) can't handle the full request rate, (3) you want to return a fast acknowledgment (202 Accepted) to the client without waiting for processing to complete, or (4) you need guaranteed delivery even during traffic spikes. The pattern is: API Lambda quickly validates and enqueues the message (fast, cheap), then a separate processor Lambda pulls from the queue at a controlled rate (reserved concurrency limits DB connections). This decoupling is the single most effective serverless overload prevention strategy.

Should I use DynamoDB on-demand or provisioned capacity mode to prevent overload?

Use on-demand mode for: unpredictable or spiky traffic patterns, new applications where you don't know the traffic shape, and workloads where cost predictability is less important than availability. Use provisioned mode with auto-scaling for: predictable traffic with known patterns, cost optimization at scale (provisioned is cheaper for steady-state traffic), and when you need to set explicit throughput ceilings to protect downstream systems. On-demand mode can still throttle during extreme sudden spikes (>2x the previous peak within minutes), so it's not truly unlimited — but it handles most real-world scenarios well.

How do cold starts contribute to serverless API overload?

During traffic spikes, Lambda needs to create new function instances. Each new instance incurs a cold start (1-10 seconds depending on runtime and package size) during which the request is waiting. If many cold starts happen simultaneously, requests queue at API Gateway, potentially hitting its 29-second timeout and returning 504 Gateway Timeout errors. Clients then retry, creating more requests and more cold starts — a vicious cycle. Mitigate with: provisioned concurrency (keeps instances warm), smaller deployment packages (faster initialization), lighter runtimes (Node.js over Java), and Lambda layers for shared dependencies.

How effective is CDN caching at reducing serverless API load?

For read-heavy APIs, CDN caching (CloudFront, Fastly, Cloudflare) can absorb 80-95% of traffic, dramatically reducing Lambda invocations and DynamoDB reads. Even a short TTL of 10-60 seconds provides massive protection during traffic spikes — if 1,000 users request the same data within 60 seconds, only 1 request reaches your origin. Configure cache keys carefully: include relevant query parameters and authorization headers, but exclude anything that would create unique cache entries per user for public data. For dynamic, per-user content, consider a 'stale-while-revalidate' strategy where CloudFront serves slightly stale data while fetching a fresh copy in the background.

Preventing API Overload in Serverless