Best way to design a billing system for a SaaS

Question

i am working on a SaaS project that provides some services that people can call via API. My problem is how do I build the billing algorithm. I want to charge on every call to the service.

Now I'm looking for ways to make the call faster and I fear adding a billing algorithm to would make it slower. Because the billing has to access database and all.

Also from my understanding it's best to use queue for any other job not required by the user. So I'm thinking of adding the billing algorithm to a queue.

But that would mean, having like millions of jobs in queues for my rabbitMq, which can loose data, and if I loose data, I loose money.

Please would like an input on how I should structure the billing system. Would also like to know I'm I just too concerned about speed and I should just put the billing algorithm in the same API call.

Answer 1

I solved a similar problem with a local copy of the account data on each node in the cluster. They only need a list of valid account identifiers and count of billable events processed on each node, so this was a simple in memory data structure that they synced every n seconds with a central datastore. In this way each node could handle several thousand API calls per second, without pushing the complication and expense of a high volume of traffic deeper into the infrastructure.

This yielded a reasonably accurate and low latency running total for each account. But it didn't have the reliability or detail to be billing data. For that we used log files: simple rolling text files that were regularly uploaded to S3. These were then processed by Hadoop and spit out into a SQL database. There are less expensive ways to do this -- terabytes of daily log files are expensive to keep and process -- but we prioritized having a permanent record for billing and data mining.

Answer 2

I attended a talk by Vodafone a while back about how they manage to do this for calls, texts, internet etc.

Needless to say its a major problem for them as people have to be prevented from using services when they run out of credit, they need to process the billing and get an answer back immediately. Their solution was a massive Europe wide project costing millions of pounds. Worth looking into, but difficult to summarise.

I would go with a NoSql customer db, where you query and update a total each call. This will allow you shard your service by customer and prevent a bottleneck on the db access.

The rational for NoSql over a relational DB Approach is that the entire customer record is retrieved at once, rather than linking a customer to billing events which then have to be aggregated in a table operation.

Because all the billing events that a customer creates will naturally be for the same customer you can split customers over multiple servers, all the A's on server 1, all the B's on server 2 etc avoiding the bottle neck of each database having to contain all the data.

Some would say its the classic use case for such a database.

However, I would advise avoiding the problem if at all possible and just running a bill off per customer at the end of each month. A far easier task.