You’ve deployed 50 Lambdas.
Can you answer these 3 questions?
The engineer who shipped the first Lambda on one of my recent projects looked at the console two days in and asked me, “Why is it slow only sometimes?”
I gave him the usual answer: cold starts, provisioned concurrency, keep it warm.
He nodded, opened the AWS docs, and came back an hour later more confused than before. The docs tell you what Lambda does. They rarely tell you what it actually is.
Every backend engineer uses Lambda, but almost nobody knows what happens between the request hitting the API and the handler running.
This knowledge gap is why your database falls over during traffic spikes and why cold-start mysteries drag on for weeks.
The 3 questions I ask anyone who says they know Lambda:
<ol>
<li>What runs your code?</li>
</ol>
It isn’t a container. It’s a Firecracker microVM. Amazon built a custom hypervisor because Docker couldn’t boot in milliseconds. Your function lives in a sandbox that gets spun up, frozen, and recycled on a schedule you don’t control.
<ol>
<li>Why is the second invocation faster?</li>
</ol>
Lambda caches the execution environment. Your global-scope code runs exactly once per environment. This is why shoving initialization inside the handler silently 10x’s your cold-start cost.
<ol>
<li>Why do teams hit concurrency limits they never set?</li>
</ol>
Account-level concurrency is a shared pool across every function in your region. One misbehaving Lambda can throttle everything else you own, and the console won’t show it until the incident is live.
If you can’t explain what happens before your handler runs, you’re shipping code you don’t control.
Full breakdown in the video → <a href="https://www.youtube.com/watch?v=ZPFS47qqUYI" target="_blank" rel="noopener nofollow">https://www.youtube.com/watch?v=ZPFS47qqUYI</a>
#AWS #Lambda #Serverless #SystemDesign #BackendEngineering

AWS Lambda Architecture