[jjeaff]

But are they really paying too much? I can't think of a lot of products out there, especially those that have a recurring subscription, that don't required some sort of database. So you need a server running a database anyway. It seems that the subscription logic would be a very negligible addition to the instance you have to be running anyway.

To me it seems like the only sweet spot for lambda on a large scale would be for those that have consistent usage of a small instance that have some extra functions that need to be highly scalable and are very inconsistent.

[PaulRobinson]

There are multiple alternatives to running your own DB service, and again, all pay-per-use.

In the original article the author suggested on a successful subscription a write to the MailChimp API (because that's the product). In that example, MailChimp is the DB. You don't have to run a copy of a DB locally if you architect things like that. Obviously if the call fails, you need to think about what you fall back to, which is why error handling is such a critical piece of the the Lambda ecosystem - as it should be for every ecosystem, really.

[lsaferite]

In this case you should really just dump the subscription on a queue (SQS) and process the payment to mailchimp on a different thread that can deal with errors.

[kagx]

For data storage, you can use aws DynamoDb (NoSQL), which has some generous monthly free tier.

[simonpantzare]

You could use DynamoDB and S3 for persistence if you're taking the AWS route.