#ds_best-practices

1 messages · Page 1 of 1 (latest)

radiant thistleBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1357400107418648589

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

fringe laurel
#

Hi 👋

If you are concerned about hitting rate limits when using the Price API, you can store the Price data locally and update the data when it changes.

You can listen for the price.updated webhook event to keep your local Price objects in sync.

#

Do you have a measurement of how frequently thes requests would occur? Our live mode limit is 100 requests per second, which is actually quite a lot.

ionic ruin
#

We have thousands of DAU, with the new product launch, we will see lot of traffic come at the same time. 100 RPS means 100 concurrent users right? How does that work companies like OpenAI without hardcoding the price info / caching the response

fringe laurel
#

Yes if you are triggering a new request for each user, and you have more than 100 concurrent users, then that will exceed the rate limits.

Most companys with higher throughput take the approach I outlined above. Prices are generally static and only update when you make changes to them. So it doesn't make sense to rely on the Stripe APIs to constantly retrieve the same data for each customer.

#

FWIW I built this approach into my initial test integration. I use an asyc task queue called Celery and I listen for Stripe webhook events. When I receive one, I check for the existence of that object in my PostgreSQL database. If it does not exist, I create it. If it does exist, I update it.

I've had this same test integration running for 3.5 years and my data has remained in sync.

radiant thistleBOT
ionic ruin
#

thanks Snufkin. The other option is request caching, however the users will see stale data unless invalidate the cache manually

agile canyon
#

Hi hi! I’m going to be taking over for my colleague here. Give me a minute to read back and understand things.

#

How often do you update prices?

#

And where/how do they get updated?

ionic ruin
#

we don't plan to change prices a lot. In the initial days, we will do a lot of experiementation & A/B testing

#

we will use dashboard to update the pricing

agile canyon
#

Ok. And how many prices total do you have (ballpark)?

#

Sorry, wrong question.

#

How many prices might be shown to customers at any given time?

#

(essentially: "how many would you need to cache")

ionic ruin
#

4

#

I think caching the responses in-memory seems like easiest and best way to get started and get around the RPS limit

agile canyon
#

Ya. And just invalidate the whole cache if you get any price.updated event. There's still potentially some delay, so maybe worth adding a way to flush the cache in your admin tooling as well.