CODEWITHSUNDEEP
architectureapi-keyrate-limitinggoogle-search-api
hitesh kaushik
hitesh kaushik

Reputation: 110

Architecture: managing pool of api keys

Background:

Looking for possible solutions on how to:

  1. provide a valid key from the pool to the frontend logic when a user logs in to the platform website (note that the user may or may not use embedded google search, but the frontend should always have a valid key with them in case the user performs an embedded google search).
  2. track the number of times an API key has been used in order to know when a key has exhausted its quota.
  3. what kind of store to use for storing these keys?
  4. enable `rate-limiting on tenants or users so that everyone gets a fair share of total calls available.

Upvotes: 0

Views: 437

Answers (1)

Cosmin Ioniță
Cosmin Ioniță

Reputation: 4055

First of all, this idea of UI calling directly an external API by having access to the API key doesn't sound good to me from a security perspective. I would still consider using a thin backend layer to validate the request before calling the external API.

Now to your question, Google APIs already have ways to monitor API usage, which is something I would consider in the first place, because depending on the scale of your application, keeping track of API usage might be problematic to manage.

You can also cap the API usage per user to make sure you don't reach that 10K limit, which is essentially what you're looking for - rate-limiting users if they reached their assigned quota. This works for some Google APIs as far as I see, needs some checking to see if it works for the search API as well.

Now if you have strong reasons to do it yourself, you can store the keys in a fast No-SQL cache, like Redis. It may need some custom logic to always give you the API key which has the smallest number of invocations, but that can be figured out for sure.

Rate-limiting can be done using Bucket4J or a similar library.

Upvotes: 1

Related Questions