When serverless fits

Cloud, deploys and infrastructure Mid-level Python 3.13+ PostgreSQL 17+ Reviewed By Best Latest Apps

Pick the fix

A Lambda spike to 800 concurrent instances exhausted Postgres's max_connections. Fix?

Options
Hint 1 of 1

How many connections does each instance open?

Choose an answer, then open Show answer below to check it.

Show answer

Answer: A Put a pooling proxy in front of Postgres and cap function concurrency

Correct. Many instances share few connections.

Each function instance opens its own connection, and Postgres runs one process per connection. A pooler such as RDS Proxy or PgBouncer multiplexes many clients onto a few connections, and a concurrency cap bounds the burst.

Why not the others?
  • B Raise max_connections to 10,000. Each connection costs memory; Postgres degrades.
  • C Open a new connection per query. More connections, not fewer.
  • D Disable retries. Doesn't change the instance count.

30-second answer

Functions (AWS Lambda, Cloud Run functions) fit spiky or low-volume work, event handlers (a file uploaded, a message arrived) and glue code: you pay per use and scaling is automatic. They fit less well for steady high traffic (often cheaper on containers), latency-critical paths that can't absorb cold starts, long-running jobs beyond the time limit, and anything holding many database connections, since each instance opens its own.

Practise saying it · 25 s. No recording, just a timer

Serverless fit.

Say your answer out loud, then check which of these points you covered:

  • Spiky and event work
  • Cold starts, time limits
  • Connection fan-out
  • Idempotent handlers

Deep dive

Use a connection proxy (RDS Proxy, PgBouncer) when functions talk to Postgres.

Provisioned concurrency trades cost for no cold starts.

Keep functions idempotent; events may be delivered more than once.

Local testing and tracing need extra tooling.

Common mistakes

  • Thousands of function instances each opening Postgres connections.
  • Running a constant 2,000 rps API on functions without checking cost.
  • Assuming each event arrives exactly once.

Senior take & follow-ups

Good fits, poor fits with reasons, and the connection and idempotency gotchas.

Follow-up questions

Think of your answer first, then open the hint.

  1. How do you protect Postgres from function fan-out?

    Show hint

    A pooling proxy and a concurrency cap.

  2. Why idempotent?

    Show hint

    Event sources retry, so duplicates happen.

Related questions

Suggest a fix if something here is wrong or out of date.