In reply to @chronos.vitaqua "That seems like it'd": It highly depends on how
you want to do your business logic.
You can write to db an entry with creation-datetime, "last
update-datetime-that-was-responded-to",
"last-access-attempt-datetime-even-if-it-failed" and id of a given user.
If your rate limiting is based on data instead of requests, also store the
amount of bytes they've been served until now and their specific limit (if its
different per user).

You can then, when a request happens, first make a call to the DB that checks if
the user has an an entry within the rate-limit timeframe based on either
creation-datetime or "last-update-datetime-that-was-responded-to" and if they
do, if they already used up their limit for the timeframe.
That can all be done in SQL in a single query and you just get back the boolean.
Given that the data you send back is just a boolean and all the logic happens
server-side, that is rather cheap, you just pay a single SQL query and basically
network transfer time from server to db back and forth once.