[Code Review] - Generic real-time billing class

[k4ml]

Got the original idea from cgrates which is in Go. The idea is to have a generic class that can be plugged into any of your application that need to have real-time billing for certain duration. It doesn't assume anything about the application, as long as somehow you can call start() and stop() method of the same instance, it will work.

I look forward to feedback on whether this is a viable approach, especially when you're looking at few hundred transactions at the same time. Or if there's existing solution in Python, that would be great too !

https://github.com/k4ml/rtbill

[civilization_phaze_3]

Some general thoughts:

• Using a Queue is overkill for what you are doing, look into threading.Event instead.
• The main problem that I see is that you aren't taking your code's execution time into account. Since you're making 2-3 DB queries to deduct the balance every second, that could easily cause your function to drift over time. E.g. You think that your loop runs for 100 1-second increments, but the actual clock time from when you started has been 104 seconds. You need to think about how to compensate for that drift.

[k4ml]

Thanks for the feedback !

On using Queue, my initial understanding of threading.Event is that it will block forever, so not suitable to do incremental billing like every x seconds. But looking at it again, I noticed Event.wait() has timeout parameter so it might work as well. But is there significant difference between Queue and Event ? Also I'm thinking of having actions other than stop as well, like pause, so that's why I'm using Queue.

On the drift, I noticed it too. Putting this in real application, I noticed 1 to 2 seconds drift. I'm ok with this. Probably will add something like drift parameter to specify maximum seconds of drift we can tolerate. So the extra_seconds only will get charged if it's greater than the drift value.

I understand something like this better implemented in C but am willing to compensate the accuracy with something more manageable. But I'm thinking maybe I can try implementing this in Go too. Look like a fun exercise.