Architecture for keeping track of API credits?

Question

I have a user table, with an api key column and total credits/used credits columns.

A user gets an API key, using that key, they can use my API, but only if used credits<=total credits .

Since, this is an API, I might easily be serving dozens of requests per second. So that rules out reading/writing directly from the DB on each call in some kind of API middleware.

So, what's the right way to do it?

• Should I try storing api-key:remaining credits as a key value pair in redis and use that in every API call?
• What happens if I have multiple server nodes and one reads from redis that there is one credit left and starts doing an API call, but in the middle another node sets the remaining credits to zero? (ie, weird concurrency edge cases)

In general, I need the solution to be highly scalable and support high concurrency (>100 reqs/sec per instance and say >100M API calls/month).

Any ideas?

Answer 1

• Use Redis for storing API keys. You don't need to set amounts here. Just key TTL and API key.
• Use Apache Kafka or something similar to receive customers transactions: debit or credit
• Use the final stock table as "customer's bank account", This table will receive the sum of all debit and credit transactions from the message broker. Calculate, send requested credit or message about insufficient funds to the customer.

Something like that. PS You also can limit transactions in seconds by key. But it is optional.