#muradlikessvelte_best-practices

1 messages · Page 1 of 1 (latest)

cinder obsidianBOT
#

👋 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/1277586976459198475

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

surreal pendant
#

Hi, let me help you with this.

#

You could probably just have multiple Products+Prices for that.

#

Since I assume, each limit has a different cost?

versed mortar
#

My current structure is 3 products with flat fees (good, better, best), each one with two prices (one for the monthly and another for the anual). I also have a different product to handle the overage with just one monthly price and is pay as you go with a price of $1.5 MXN per unit.

So I also, I would like to know if my pricing structure is well planed to scale effectively or if is there something that can be improved? Any improvement is much appreciated!

image.png
versed mortar
surreal pendant
#

I don't think entitlements is needed here.
This looks fine. I suggest having 4 Products (Basic, Pro ...), with each having 2 Prices - monthly and yearly.

versed mortar
surreal pendant
#

Correct.

versed mortar
#

Thank you for your guidance, I will avoid entitlements and features for now.

Another question, in my own postgresql database, would you recommend me store the subscription data (current_period_end, current_period_start, status, etc) all as a json column or a column for each key? same question for customer data?

surreal pendant
#

There's no reason to store duplicate information in your own database, since you can always access it via Stripe API.

versed mortar
#

I understand the recommendation to avoid storing duplicate information. However, my use case involves very frequent access.

Checking Subscription Status:
• This occurs every time a client views a restaurant's menu
• Expected to happen very frequently
• Potentially many events in short time periods

Concerns:
Is the Stripe API sufficiently fast and reliable for this high-frequency scenario?
Can the limits of the Stripe API handle numerous requests in rapid succession?

#

If I'm not wrong, the webhooks are made to store duplicated information and keep in sync the main database so it can be accesed fast and reliable

surreal pendant
#

Stripe is also highly reliable.

#

However, you can always implement some kind of in-memory caching, rather than storing it in your own database.

cinder obsidianBOT
versed mortar
#

Does that means I will don't need to set up the webhooks and stick with calling the stripe directly? 🤔

So for what the webhooks are recommended?

surreal pendant
#

Webhooks have their own use case, e.g. notifying you of successful payments so you can start fullfilling the order

versed mortar
#

local storage?

surreal pendant
#

I don't know, it depends on your own app/technology/architecture.

#

Don't get me wrong, saving some information in your own database does have use cases as well, but it's not always necessary.

versed mortar
#

That's great

#

Thank you so much for all your guidance, I was in the wrong path

#

This conversation has been so much useful

#

❤️

abstract lichen
#

hi! I'm taking over this thread. let me know you have any other questions!