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.

  • 2
    Sorry, I am sure noone here can seriously tell you if you are too concerned about the performance of something you did not implement and measure so far (except the general advice, implement and measure first, and optimize when you have the numbers on the table, not beforehand). – Doc Brown Oct 5 '17 at 13:27
  • 2
    honestly I think this is classic scaling problem and an ideal question for this site – Ewan Oct 5 '17 at 19:25

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.


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.

  • So you attended a talk by Vodafone, but what did those Vodafone people tell you how they approached the problem? – Doc Brown Oct 5 '17 at 13:30
  • 1
    lots and lots of computing power and millions of pounds of development. – Ewan Oct 5 '17 at 13:43
  • 3
    You haven't provided any rationale for NoSQL (which is a marketing term, by the way, not a technology). There are critical issues with "NoSQL" databases like eventual consistency, which you haven't even touched on. – Robert Harvey Oct 5 '17 at 18:29
  • edited. I thought it was pretty self evident tbh – Ewan Oct 5 '17 at 19:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.