Post

An eng manager at Netflix once told me that "It'd cost 7x to run Netflix if Netflix ran on Lambda". But what he said next was even more insightful. "But, not everything at Netflix runs at Netflix scale." And that's true for most enterprises!

When I was at DAZN, we didn't operate at Netflix scale, but we still had to deal with millions of concurrent users at peak. Services along our critical path will experience sudden spikes from hundreds reqs/sec to tens of thousands reqs/sec in a matter of seconds.

But outside of that critical path, Lambda was used heavily across many workloads, including critical business areas like payment processing & account management. Even some services on the critical path were able to use Lambda and API Gateway because their API responses were highly cacheable.

So a quick rule-of-thumb from a throughput POV is: * Stable high-traffic workloads => containers * Bursty, occasional workloads => lambda And don't forget about caching. It's literally a cheat code for building scalable and high-performance systems!

So don't create your frontend application's backend REST API (BFF) in Lambda with API Gateway

I said REST API backend not GraphQL though. Also wasn't your conclusion to not use Lambda with stable high traffic needs like, say, a website? I think a lot of people use Api Gateway to do exactly that

You missed the "high-traffic" bit.

Websites are often more stable than bursty, unlike with some batch/report service. What is your definition of high-traffic then, if your conclusion is that Lambda is okay as a BFF REST API backend for websites? What else is stable "high-traffic" as an anthesis to burst?