How to design real-time debiting of money from the user's account?

Question

PHP

Good evening, colleagues!
Please tell me the best way to implement the following function on the site.
There is a certain service, let's call it "paid ad placement". The cost of accommodation is fixed (say, 100 rubles per day). Users replenish the balance and enable/disable their ads. Moreover, in addition to manual on-off, there are still a lot of criteria by which ads can be turned on or off.
The goal is to show the user's ads only when they have money in their account. As soon as the money runs out, in the same second, ads should stop appearing on the site. As soon as the account is replenished, the display should instantly resume.
Those. you need to know at any time how much money is in the user's account.
Bad decisions.
1. Run on CRON every second recalculation of account balances of all users. Not suitable - too resource intensive.
2. Calculate and keep up to date the date and time when the user runs out of money. This is how this task is implemented now, but this is a rather difficult solution to maintain and implement. As ad enable/disable conditions increase, this becomes hell.
Can you please tell me what other options are there to solve this problem? Will Node.JS help? Or some other technology? What key phrases to google?
The site is written in PHP (symfony 1).

Answer 1

Directly per second billing?
If it's not a secret, please tell us what kind of service.
An analogue from the industry where it's all standardized and worked out.
In connection, there are 2 payment methods: postpaid and prepaid. Postpaid is, roughly speaking, an account that can go negative, in this case by.
prepaid. This is the method that takes money before the start of the service, so when it approaches 0, it turns off the service. For example, in a number of countries it is forbidden by law to take a pre-paid subscriber to a minus, but this is lyricism.
So, there are two types of prepaid (the main ones, in fact, there are more)
IEC - Immediate Event Charging and ECUR - Event Charging with Unit Reservation.
In the first case, when an event occurs, a request is made to the account, the account is checked and the cost of the service is cut off from it, after which a positive response is returned and the event continues. The problem is the tie per unit of billing, if you choose a small one (second), then it turns out to be very resource-intensive, and if you increase the quota (up to a minute), then if you refuse the service at the 35th second, the funds will disappear in 25 seconds. Probably a familiar situation...
The second method is more interesting.
2 options are selected. Quota size and billing unit, let's say 1 minute and 5 seconds. The event is triggered, a request is made to the account, the amount is blocked on the account, and a response is returned that contains the amount available for the service (in the example, time, but there may be bytes, clicks, elephants ...) And the service begins to be provided. As soon as the resources run out, the account is again contacted, which says that the resources have been used up, and I want more (well, or I don’t want to), in this case, the reserved amount is debited from the account, and the next quota is reserved. If the service is terminated before the quota is exhausted, then the time is rounded up to the billing unit (from 32 seconds to 35) and money is debited only for 35 seconds, for 25 seconds it is returned.
This is how the work with the account is organized.
You can read in more detail here www.3gpp.org/ftp/Specs/archive/32_series/32.299/32299-700.zip Item 6.3.2, you don’t need to be scared, the pictures are understandable.
Wow signed up. This is half, the second part is how to control each event. And here without an example I can not say anything.

Answer 2

> The cost of accommodation is fixed (say, 100 rubles per day).
Then what's the problem?
How much time at least this advertisement should hang is always known!
This parameter changes to a lower side when placing another ad by the same user.
This parameter changes upwards when “replenishing the balance” and when other advertisements are removed.
So the event-based data processing model will completely solve your problem.

Answer 3

I propose this option:
It is necessary not to enable / disable ads, but to check the user's balance, if <=0, then do not show.
And select ads for display, where the balance is> 0 and the ad is enabled by the user + criteria.
That is, the enabled/disabled field should be changed only by the user, and not by a mass of criteria.
The criteria must be spelled out in the ad itself.

Answer 4

It is enough for each request that is related to the ad (start\stop\display) to run a function that checks the current balance and, if it is greater than zero, then calculates a new balance and displays the ad. Something like that, nothing complicated.
Or is it necessary that the server constantly knows the current balance?

Answer 5

Only “events”: start, stop, manual start of a new ad, replenishment of an account - everything that changes the forecast for money, triggers an event that updates the date-time of the end of money on the account, according to which the server will turn off the display.
The only task assigned to the crowns is to find, by all accounts, whom it is time to chop off.
Switching on from the “off” state is possible only on account replenishment event.

Answer 6

One solution is to rethink the billing model. Introduce the concept of funds reservation. When adding an ad, the user himself indicates for how long it will be included, for example, for 1 day. And the corresponding amount is reserved, if it is on the account and not reserved, even before the ad is shown. Thus, we know in advance the moment when the ad should be disabled. And there is no need to check the balance every second.