> because of your security-based product Nothing in the article has to do with the product or the fact that it's security related, other than to provide a moti

> because of your security-based product Nothing in the article has to do with the product or the fact that it's security related, other than to provide a motivating use case. > The only potential benefit there was for security And performance. > even that was just relying on the ephemeral nature of lambdas I think you've failed to understand the article, which may be my fault, I haven't read it in a long time. The key is isolation. Ephemerality gives you a sort of temporal isolation. Splitting your messaging from your data storage gives you a capability based isolation. And so on. It also means we can scale to the limits of S3/SQS - each service is itself stateless, the majority of state is managed in SQS, which could be quite loose about its consistency since every service is idempotent - arguably a form of temporal isolation. What I've described in this article is effectively the actor model. I feel like I don't have to really justify the benefits of the actor model with regards to scale?