Published 3 months ago by behnampmdg3
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.
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.
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.
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?
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.
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.