A design question. What if the customer don't upgrade? How can I limit the service?

Published 3 months ago by behnampmdg3

Hi;

It's a monthly payment system. The client can buy 3 account types:

1 - Basic, 2 - Pro, 3 - Consultant

Basic allows them to have 10000 emails in their account. Pro allows them to have 100000 emails in their account. Consultant allows them to have 200000 emails in their account.

They can add prospects emails to their account using my API endpoint.

Scenario:

If they buy a Basic account and at some point the number of the emails in their account increase over the limit:

1 - How can I give them X days to upgrade and what if they don't upgrade? 2 - How can I calculate the number of days they've been over the limit (without making things complicated and shet in the code)

I want to give them maybe X days notice. After that 2 things could happen:

1 - They upgrade 2 - They don't upgrade

What if they stay on the same account type? I can't cancel their account because they still paying.

Tanx

Best Answer (As Selected By behnampmdg3)
Cronix

It's the same basic principle as gates/policies. All a policy does is check whether a request is able to be executed based on whatever criteria you tell it. If not, don't allow it. However that principle gets implemented is up to your requirements.

Your requirements just need to be very well defined. Write a step by step policy in chronological order based on what happens, when, and under what conditions.

If you want to do something x days after they don't upgrade, then that is just a logic question based on how you are setting their subscriptions up. I'm sure there's some date stored somewhere about when the subscription was started, and the frequency it renews. So you can just do some date math there and do something x days after their subscription expires. These kinds of things are best done like using a queue with a delay (so when subscription expires, add something to the queue for 2 weeks after that or whatever), or scheduled tasks.

But it's really hard to know what to do without knowing the entire layout and business logic of how everything works. How do these "widgets" on other peoples websites work? Do they use some api on your server or something, sending their token and stuff? That's where you'd implement the policy. When they hit the api...do the checking.

Cronix
Cronix
3 months ago (730,880 XP)

It's pretty simple really. They're hitting controllers to do these actions, correct? Just store stats on what they're doing in a table. Just increase a counter or something where it starts at 0 each month. Then before allowing them to do things, first check to see if they're within their limits based on their plan. If they're allowed 5k messages, maybe send them a notice at 4500 messages and let them know they're near their limit, and to upgrade if they need more. Once they hit 5k, just don't allow the action to go through. You don't have to cancel anything. Just send a message, "We're sorry, the x plan allows for 5k messages/month, and you've sent 5k messages this month. Please upgrade for a higher limit." type of thing. The checking can be done with laravels built-in authorization functions.

https://laravel.com/docs/5.6/authorization

behnampmdg3

I hear you. For simple products that works.

This one is B2B.

Can't phuck with "their" customers. They use these widgets on their sales pages.

I still notify them with emails and alerts on the website. Need to also disable the widgets they add to their sites. https://snag.gy/t1Bhao.jpg

Maybe disable the widgets after X days be a good idea.

That brings me to:

==> "When did they go over the limit" <==

and give them 2 weeks time from that date (before unplugging).

See where this is going?

Cronix
Cronix
3 months ago (730,880 XP)

It's the same basic principle as gates/policies. All a policy does is check whether a request is able to be executed based on whatever criteria you tell it. If not, don't allow it. However that principle gets implemented is up to your requirements.

Your requirements just need to be very well defined. Write a step by step policy in chronological order based on what happens, when, and under what conditions.

If you want to do something x days after they don't upgrade, then that is just a logic question based on how you are setting their subscriptions up. I'm sure there's some date stored somewhere about when the subscription was started, and the frequency it renews. So you can just do some date math there and do something x days after their subscription expires. These kinds of things are best done like using a queue with a delay (so when subscription expires, add something to the queue for 2 weeks after that or whatever), or scheduled tasks.

But it's really hard to know what to do without knowing the entire layout and business logic of how everything works. How do these "widgets" on other peoples websites work? Do they use some api on your server or something, sending their token and stuff? That's where you'd implement the policy. When they hit the api...do the checking.

behnampmdg3

Yes, this is a biz logic question.

And again yes, when the endpoint receives leads, I have to perform a count and check this.

I am trying to avoid using workers at the same time keep the endpoint as light as possible.

API endpoint seems to be a good punching bag for extra queries etc.

behnampmdg3

Maybe I can set cronjobs in whm

behnampmdg3

Dude, setting cronjobs will take so much pressure off my api endpoint too!

I dont need to set up workers either.

I add everything to db, then later check it with cron job and classify/delete the garbage etc.

Snapey
Snapey
3 months ago (995,145 XP)

could you in some way quarantine the overspill so that the information is recorded but the customer cannot do anything with it?

behnampmdg3

Need to get creative with this. Thanks

Please sign in or create an account to participate in this conversation.