Serverless Mental Models: What They Don't Tell You Before You Build
Four mental models for serverless past the deploy-a-Lambda tutorials: it has real limits, stateless is not the same as simple, failure domains are the actual value, and you only understand it once you've deliberately broken it.
Most serverless content stops at "here's how to deploy a function." This post is about the thinking that comes after that, the mental models that separate someone who can ship a Lambda from someone who can design a system out of them. It's honest about the trade-offs and says out loud when something else is the better tool.
Four models. One, serverless has real limits: cold starts of 100ms to a couple of seconds, a 15-minute execution ceiling, a cost crossover somewhere around 30 to 40 million requests a month, and a genuine mismatch with stateful workloads. Two, stateless is not simple: the complexity doesn't vanish, it moves into your databases, caches, and queues, and idempotency becomes mandatory because at-least-once delivery and retries guarantee duplicate invocations. Three, failure domains matter: the real payoff of serverless isn't cost or autoscaling, it's blast-radius isolation, which you lose the moment you synchronously chain Lambdas into a distributed monolith. Four, build and break it deliberately: you learn the failure modes by testing them with CloudWatch Logs, X-Ray, and dead letter queues, not by reading.
Key takeaways
- Cold starts aren't negligible on user-facing paths, and Provisioned Concurrency fixes them by giving up pay-per-use; decide per workload
- Stateless pushes distributed-systems complexity outward, doesn't remove it: FIFO queues still allow duplicates outside the dedup window, shared layers couple every function
- Failed async invocations vanish without a DLQ: if you can't name where a failure goes, you have a gap, not a failure domain
Who this is for
Developers who've done the serverless tutorials and are now designing something real. Assumes you've deployed Lambda and API Gateway and want the architectural framing that the getting-started material skips. Pragmatic in tone, written from production experience.
The full piece, with each model worked through, is on DEV.to.