Serverless Architecture Explained: It Is Not No Architecture

Serverless does not mean no architecture. It means your architecture moves out of code and into config: IAM policies, API Gateway routes, Lambda functions, Step Functions state machines, EventBridge rules. The diagram changes shape but it does not go away.

The pattern that shows up over and over: clients hit an API, the API publishes work as events instead of doing it inline, a queue buffers spikes, functions scale horizontally to drain the queue, and results land in storage that can trigger more events. Async by default, retries built in, pay per invocation. For the right workload this is fantastic.

The new first-class constraints are the ones you did not have on EC2. Cold start latency. Execution timeout. Package size. Concurrency limits, both per function and per region. The cost model flips: you pay per request, not per hour. That is a strict win when traffic is spiky and a strict loss when traffic is sustained and high.

Where serverless wins: event-driven glue code, intermittent jobs, fan-out workers behind a queue, scheduled tasks, anything where average utilization on a dedicated box would be under twenty percent. Where it loses: low-latency steady-state APIs, stateful workloads, anything that wants a warm in-process cache or a persistent connection pool.

The production failure I watched. A team built a high-throughput public API on Lambda behind API Gateway. Traffic was steady at a few thousand RPS during business hours. Cold starts caused p99 latency to spike to three seconds whenever the platform recycled containers, which it did constantly under that load. The team turned on provisioned concurrency to keep warm instances pre-allocated. p99 dropped to two hundred milliseconds. The bill grew by 5x compared to a sized EC2 fleet running the same QPS. They had paid the serverless premium for steady-state traffic that was never going to be bursty.

The fix was a split. The bursty paths stayed on Lambda: the webhook ingestion endpoint, the async image processing pipeline, the nightly report job. The steady-state hot path moved to an ECS service behind an ALB. Cost dropped back. Latency stabilized. The serverless pieces still handled the unpredictable load that would have required overprovisioning on dedicated compute.

The other things that bite in production: idempotency, because at-least-once delivery means duplicates will happen. Dead-letter queues, because some messages will never succeed. Distributed tracing across API to queue to function, because logs alone will not save you. Backpressure caps on concurrency and batch size, so a runaway producer does not melt a downstream database.

Serverless is a tool. Use it where the cost curve and the workload shape agree.