The Engineer’s Guide to Serverless:
When It Helps and When It Hurts

The Serverless Promise

Serverless computing makes a compelling promise: you write business logic, the cloud provider handles everything else. No servers to patch, no capacity to plan, automatic scaling, and a pay-per-execution billing model that can dramatically reduce costs for spiky workloads. For the right problem, that promise holds up remarkably well.

Event-driven background processing, API endpoints with unpredictable traffic, scheduled jobs, webhook handlers, image processing pipelines serverless handles all of these exceptionally well. The operational overhead reduction is real and significant. A Lambda function handling S3 event notifications requires no server management whatsoever, scales to zero when idle, and costs essentially nothing unless it’s actually running.

Where Serverless Works Best

The workloads best suited to serverless share a set of characteristics: they’re triggered by events rather than running continuously; they execute in bursts with variable or unpredictable frequency; each execution is independent and stateless; and they complete quickly enough that cold start latency is negligible relative to execution time.

• API backends with variable or bursty traffic patterns where paying for idle compute is wasteful
• Async processing image resizing, document conversion, email sending, notification dispatch
• Scheduled tasks daily reports, data cleanup jobs, periodic sync operations
• Webhook receivers that need to handle external events reliably without dedicated infrastructure
• Edge functions for authentication, routing, personalisation, and A/B testing at the CDN layer

The teams that get the most from serverless adopt it surgically for the specific workloads where the trade-offs work in their favour rather than treating it as a default architecture for everything.

Where Serverless Hurts

Cold starts are the most frequently cited limitation, but they’re also the most frequently overstated. For most workloads, cold starts are a latency concern only for the first request after a period of inactivity. Provisioned concurrency eliminates them for critical paths, at the cost of losing the pay-per-execution benefit.

The constraints that genuinely hurt in practice are less glamorous. Execution time limits (15 minutes on AWS Lambda) rule out long-running computational tasks. Connection pool exhaustion is a real problem when many function instances try to connect to a relational database simultaneously a problem that requires a connection pooler like RDS Proxy, which adds cost and complexity. Local disk storage is ephemeral and limited, which matters for any workload that needs to write temporary files larger than a few hundred MB.

State management is the deepest structural challenge. Functions are designed to be stateless, which means any state that needs to survive beyond a single invocation must be externalised to a database, cache, or object store. This adds latency and cost to every stateful operation. For workloads that are inherently stateful real-time multiplayer, live chat, IoT state machines serverless is the wrong tool.

The Cost Reality

Serverless billing models are excellent for low-volume or spiky workloads, but they can be expensive for high-volume, consistently active workloads. If your Lambda functions are executing millions of times per day at consistent volume, a comparable EC2 or container workload may be significantly cheaper. Always model both options for workloads above a certain invocation threshold.

The cost model that catches teams off guard: vendor-specific services that couple tightly to serverless functions API Gateway, SQS, EventBridge, S3 event notifications all have their own per-request costs that add up at scale. Model the full system cost, not just the function execution cost.

The Right Pattern

The most effective pattern we’ve seen: use serverless for the pieces of your system that are genuinely event-driven and stateless; use containers or managed services for the pieces that need persistent connections, long-running computation, or fine-grained cost control. A hybrid architecture where a containerised API talks to serverless async workers behind a queue is often the most pragmatic and cost-effective approach for most SaaS products.