How and why we use lambda in my old company

In one particular project, we encounter one serious trouble, because of it's nature.

Let me briefly tell what's going on here.

That project, we choose to use bcrypt for user password protection, good enough right? But one major concern of bcrypt is, because of it's nature(again), it constraint the amount of login request a single server can handle so hard.

For that app's size and use base, actually it's not a concern in normal case, we definitly capable to fulfil all daily access.

The only exception is, there is another nature from this app. We have some event (consider a Black Friday) will introduce a log of same time traffic request(including login), which will dramatically pike our load like 400 times.

And obviously, the first solution come to our head will be auto scaling.

We already are using AWS since lunch, and already had auto scaling. But auto scaling is not so helpful on this scenario since:

• Auto scaling is not that fast
• It will totally be a disaster to have this scale in our config

Pike traffic, and sort of computational not intensive, yes, this is why we think lambda is so good at handling.

The next step is quite obvious, we to setup a lambda function, config the network and expose it with api gateway, and thats exactly how we do.

After it, we need to figure out how to pipe it up with existing api since we don’t want to introduce any impact to existing api consumer. We end up with using existing api to serve as proxy since redirect action is not working well(also, its indeed not a website...)

End up, we have a really scalable yet maintainable serverless api without changing too much the architecture. Our next step is to study the benefit if migrate some of those small transactional api with also SNS(Or basically any other queue)

Also, we were still hiring, drop me a message if you want to know more about us.