3 ms·
Having some experience running serverless applications in a large, distributed environment, I can say that this could have easily gone very wrong. I've seen fi
by ed25519FUUU 6y ago
Having some experience running serverless applications in a large, distributed environment, I can say that this could have easily gone very wrong.
I've seen first hand how a serverless application, "scaling" to meet a huge demand, will stampede the weakest downstream service and DDoS it.
In this case they're lucky that their payment processor (Stripe) didn't start throttling them. You may have spoken with Stripe beforehand about your expected load and get some sort of agreement / whitelist for your API token. That would be very wise.
- skifunkster 6y agoIn this scenario we did have an account manager at Stripe, however fortunately and unfortunately the show brought in somewhere in the region of 7X the initial target. Servereless stampeding a payment processor like Stripe as opposed to something like RDS are two different kettles of fish, as am sure you can imagine, stripe have very high capacity and there is 1:1 relationship to the user unlike DB writes, where there may be many per transaction / action. I have don't it both ways in the past, queueing payments and processing later. Problem is with doing that you cannot immediately return card errors, which has a large effect on conversion. With something like Amazon it is fine to do that, as users inevitably come back to buy the products they want, for donations not so much.