Serverless architecture

You write a function (a handler), and the platform (AWS Lambda, Cloudflare Workers, Google Cloud Run) runs it on every event: an HTTP request, a file in storage, a message in a queue, a cron tick. No requests means no running copies and no bill for idle time.

Functions are usually surrounded by managed services: API Gateway at the edge, DynamoDB or Supabase for data, S3 for files, SQS for queues. So serverless is not only FaaS, it is an approach of «assembling the system from managed blocks».

Cold start: the first call after idle time spins up a new environment, which adds from tens of milliseconds (Workers on V8 isolates) to a second or more (Lambda on Java without SnapStart). For an API with a strict p99 target, you will feel it.

Execution limits: Lambda runs at most 15 minutes per invocation and has a default quota of 1,000 concurrent executions per region. A function keeps no state between calls, so PostgreSQL connections must be pooled through a proxy (RDS Proxy, PgBouncer), or a thousand functions will exhaust max_connections.

Serverless works great for uneven load: processing uploaded videos in ShortLesson, payment provider webhooks, nightly reports, traffic spikes after a newsletter. Between spikes you pay close to nothing.

Under steady high load the pay per invocation model becomes more expensive than ordinary containers. In 2023 the Amazon Prime Video team moved a video quality monitoring service from Step Functions and Lambda into a single process on ECS and reported a 90% drop in infrastructure cost.

Reproducing a chain of «S3 event, Lambda, SQS, another Lambda» locally is hard. Emulators (LocalStack, SAM CLI), structured logs and tracing via OpenTelemetry or X-Ray help.

Triggers, IAM policies and event formats are specific to each cloud, so moving is expensive. Keep business logic in plain modules and make the handler a thin adapter.