Serverless

Serverless is a model for running code without directly managing servers. You write a function, the provider runs it when an event occurs, and billing follows usage. Examples include AWS Lambda, Cloudflare Workers, and Vercel Functions.

How it works

1. An event arrives — an HTTP request, file upload, queue message, or schedule.
2. The platform starts a runtime and runs the function.
3. The function finishes and the runtime stops.
4. You pay for execution time and resources used.

Strengths and limits

When it fits

Serverless fits small APIs, webhooks, image processing, light cron jobs, and uneven load. It is a poor fit for long-running processes, applications needing a persistent filesystem, or services that require an always-open database connection.

What to watch for

• Cold starts. A rarely called function can be slow on the first request.
• Time and memory limits. Good for short tasks, poor for long processes.
• Egress and requests. Costs can rise with heavy traffic.
• Vendor lock-in. APIs and runtimes differ between providers.
• It is not a database replacement. Data still needs a separate service.

Serverless functions often open a new database connection per invocation. Without a pooler, the database can run out of connections under load. Use a pooler, cap concurrency, or choose a database with an HTTP API.

A minimal Node.js handler:

export const handler = async (event) => {
  return { statusCode: 200, body: JSON.stringify({ ok: true }) };
};

On AWS Lambda, cold start appears in the Init Duration metric in CloudWatch; on Cloudflare Workers, check execution time in the dashboard. Measure before choosing a provider, because documentation numbers are not your workload.

FAQ