Ahh perhaps the t should be ‘thousands’ per second then? TPS I’ve always always read as Transactions Per Second and have seen it documented as such.
it is most commonly transactions per second 
at 20,000 tps Lambda is horrible value you would be paying
$ 21,150.00 for what would cost 1K as a pair of m4.4xlarge on EC2
Ok ok, I admit that I don’t know anything about lambda, ec2 etc. 
I’m still a bit confused about the comparison of tps numbers. It will be about the full stack I assume. I thought about the transaction size. Records differ in size, transactions can be on more than one record, etc. What does this number say at all, can you compare the quality of different applications this way? I think not http://www.neotys.com/blog/how-to-test-application-throughput/
(another quick google result worth reading: https://www.rackaid.com/blog/performance-benchmarks/)
Again lambda is not a good use case for sustained large volumes of transactions. No question about it. The sweet spot is more in the < 10 M requests per months, especially when there are spikes of useage or seasonal traffic. There a lots of “apps” that never even come close to that limit.
When you count the operational aspects and HA deployment, IaaS vs Serverless/PaaS is often a no brainer.
All is a question of tradeoff, I am not sure it’s fair to say you should never use X, in my world, lambda is the first choice, nothing even comes close. At eBay or PayPal, I am sure Lambda comes last.
I’d like to add this article to the list of relevant articles: http://queue.acm.org/detail.cfm?id=2611829
The Curse of the Excluded Middle
“Mostly functional” programming does not work.
Erik Meijer
That’s a good article, but which point do you want to make with it?
1/ Direct DOM manipulations are an absolute no-no
2/ immutability buys nothing other than a big performance hit
3/ propose / accept / learn is possibly the safest way to handle side-effects in Front-End architectures (granted not in general)
?? You leave a lot to guess. As I often experienced. It’s ok for me, I might not be clever enough, you do not have to go in details. I take this explanation also for granted (btw talk to Erik about your conclusion after reading his article that “immutability buys nothing other than a big performance hit”. I’m sure he will reward you with a big smile. And a kick out of his office.).
Well at some point you have to mutate something, making the application state immutable is what buy you nothing in terms of managing mutability. Let’s compare:
var m = new Model();
m.accept(proposal).then(access)
with:
access(m = accept(m, proposal))
what’s the difference? a big malloc?
If X is a problem f(X) is rarely a solution, nor X$, not to mention, new X(). You probably need to dig a bit deeper than putting a big function box on some bad code to make it behave properly.
If you spend some time looking at TLA+ / Paxos and make an attempt to make mutation a first class citizen of your programming model, perhaps you’ll understand what I mean, otherwise, it looks like we’ll have to agree to disagree.
That being said, and quite strangely to be frank, Erik never talks about TLA+… I saw him mentioning it once in one of his talks telling the audience that he’ll have to learn about it, but he didn’t elaborate in any way.
