Best practices for high traffic

I had an event this past weekend that caused a huge, temporary increase in traffic on my app (from ~100 daily users to ~5,000+ over a few hours). I am fully aware of options to increase capacity in regards to units, etc, but I’m curious about best practices are when dealing with workflows, specifically the show-stoppers like payment processing.
I use the Bubble built Stripe plugin, and have a workflow that sends them to the Stripe fulfillment page, and when they return, creates 2 Things (a ‘payment’ and an ‘access’). There’s a few visual changes as well that happen once payment is complete.
Once I noticed the high traffic, I was able to boost the units on my plan, but for about 10-ish minutes, I was pinned at maximum capacity. During that time, there were a few dozen purchases that occurred, but the workflows that were supposed to fire after being redirected from Stripe, did not. Would triggering a backend workflow prevent this from being an issue? Is there another way of going about this that would prevent this mis-hap from occurring? It’s not super practical for me to upgrade to the Production plan permanently because this kind of traffic only occurs on a once-or-twice a month basis.

It’s been a while since I built my signup process, but a couple of things I did were:

  1. I used the plugin and had the payment info as a stripe popup on the page, rather than directing to a different page.
  2. The workflow that creates the paid customer is kicked off as soon as they clear payment, and I recall doing it as a backend workflow. I wanted to avoid a situation where it was executing on the front end, because I was afraid that the workflow wouldn’t execute if the user’s browser froze up or they closed the window.

Ok, good to hear that a backend workflow can potentially work better. It’s happened on such a small % of cases that I suspect this may be the issue–or it’s taking so long that users get impatient and prematurely refresh or close the tab. But I also wasn’t sure if scheduling a backend workflow would use any less resources. Maybe having Stripe send a webhook to a backend workflow would result in better stability?

I don’t know, but if I had to guess, a backend workflow may use more resources since you are asking for everything to happen on the backend. But the difference is probably slight if at all, since signup type stuff requires things to happen on Bubble’s end. I set mine up this way for stability purposes, rather than thinking about capacity.

The goal is definitely stability. Users are essentially purchasing access to a PPV livestream, and are often doing it in the middle of an ongoing stream. So any purchases that don’t get processed obviously results in not-happy people.

backend webhooks also work better. yes.
check this tutorial

I’m not familiar with the Bubble-built Stripe plugin, but Stripe webhooks are the way to go. I use a custom-built Stripe plugin (built in house) and Stripe’s own hosted checkout (which it sounds like you’re using as well).

We offer downloadable content, and I can tell you that the webhook has fired and the associated workflow (which enables the download) has run by the time the user is redirected back to our website from Stripe. IOW, the content is immediately available for download as soon as the user lands back on our site. There is no delay.

This is great news! Thank you. Yeah it sounds like Webhooks are the way to go. Good to have your input before putting in the work to do that. Although I think I was headed down that path anyways as the built in plugin doesn’t give me the actual fee Stripe charges. This way I could probably build a workflow in my dashboard to “check” the last hours worth of transactions or so if I do suspect missed workflows due to capacity.

The more I think of this the more happy I am about using Webhooks instead, haha. Thanks!

btw you will come across an issue (how to find the right stripe user in the backend) but when reading this, this will provide the answer.

1 Like

This topic was automatically closed after 70 days. New replies are no longer allowed.