How to Architect Individual Throttles for Users and Tables in FastAPI

Software engineering is easier than we think because sometimes the answers are simple and many times right before our eyes.

FastAPI has been instrumental to me in understanding backend engineering and thinking about processes and how stuff can and should work. It is an intelligent tool, however, it is solely dependent on your creativity and the eyes of your imagination. Here is the premise of my generalization.

If you have read any of my previous works you would know my backend origin is Django (and its rest framework), and I am grateful for its direction and its design patterns, they have allowed me to modify the wheel to suit my use case.

Growing up my pops knew my mind wondered and I wanted to create stuff and my pops always told me you cant reinvent the wheel, modify it.

I once worked on a throttled/rate-limited application or endpoint with DRF and it was amazing, I learnt something new and I was intrigued (earlier in my career). The throttle in this case affected the endpoints I applied it on, recently I was interested in doing something similar in FastAPI, and I first took the easy route (google for the win) and saw that there are packages that exist that perform the throttle action.

I personally felt they provided the same comfort and familiarity that I had when I used Django. They did not offer the flexibility I wanted (or maybe I was lazy about doing some overrides), so I then sat and architected a solution. So let's look into the code.

Disclaimer: I will not be providing information on getting started with FastAPI and doing a lot getting up to speed I will assume you can do this, if you cant check the best resources on getting started with FastAPI (, Doc Tutorial)

Demo Application: Tranzact some Fintechy (bare bones) app.

So let's create a table called Tranzact that can be used to create Tranzact data records and an API-Key would be generated to be able to identify distinct Tranzact records.

This Table and application leverage SQLAlchemy, so check out the documentation.

Here is the Router.

We can Perform CRUDy operations in the router, (If the application looks weird I will make another post on the design pattern here called Repository Design pattern).

This is the endpoint that an API-Key speaks to, this API key serves as the authentication to perform some actions. What we can see is there is a dependency that points to a transact record.

Let's examine the tranzact_header dependency and check the calls.

This recognizes the API_Key and returns the tranzact record associated with an api_key.

So to solve the challenge of individualized throttling, I resolved that while creating a record for the tranzact table. I create a record with the tranzact.id and a count with a default of 0 to the table of tranzact rate limit. Here is the table below.

So with this solution, I needed a way to track the rate limit record, with API_KEY we can increase count incremental based on each call and throttle based on the freemium role that tranzact record have. Here is what the function looks like.

So with this function, we can do some QA and check based on a flag and with the count. This depends on the api_header function. We then swap out the dependency in the API call endpoints with the throttle API rate limit function. We can do that because they both return the same Tranzact record. To understand more about the dependencies and their call with FastAPI check out this point of the documentation.

Here is a test case in my postman.

Setting up the API_KEY for my collection in postman.

Below is the throttled response for a request call that has reached the capped number, meaning that another api_key will respond differently giving up the desired response, plus if the tranzact record is premium it by-passes the throttle check.

So this is how I created singular DB record throttle, the concluding stage of my implementation includes using a celery beat job (a scheduled job/task) to revert all tranzact rate limit record count to zero on the hour. This is a personal implementation others can be done.

In conclusion, take my words below with a light heat heart but it is my truth.

Any product/feature that you can see, imagine or conceptualized irrespective of its complexity we can build, once we can see it FastAPI can help us bring it to life.

Also published here.