Public APIs
Each API key gets a limit per plan, with bursts for well-behaved clients and a precise Retry-After for the rest.
Core dataAPIs
Rate Limiting
Atomic, server-side rate limits. GCRA in one command, or named limiters with sliding window, token bucket or leaky bucket. No Lua required.
- atomic command per request
- 1
- algorithms
- 4
- Lua scripts
- 0
Step 1 of 5
Allowed
10 requests per minute for user 42. The reply says allowed, the limit, and how many remain.
Example sessionplaying
# Allowed
hotkv> GCRA.LIMIT ratelimit:user:42 60000 10
1) (integer) 0
2) (integer) 10
3) (integer) 9
4) (integer) -1
5) (integer) 6000
An animated walkthrough with real HotKV commands and example replies. Click any step to jump to it.
The problem
An API without limits is one misbehaving client away from an outage. Doing the check in application code means a read, a calculation and a write, and concurrent requests slip through the gaps between them. Many teams end up maintaining a Lua script just to make it atomic.
How HotKV handles it
GCRA.LIMIT decides and records in one step, so concurrent clients cannot both pass on the same state, and the limit refills smoothly instead of resetting at window boundaries. For limits you manage by name, RATELIMIT.CREATE sets up a sliding window, token bucket or leaky bucket limiter with statistics on what it allowed and denied.
Step by step
What happens, command by command
- 01
Allowed
10 requests per minute for user 42. The reply says allowed, the limit, and how many remain.
GCRA.LIMIT ratelimit:user:42 60000 10 - 02
A burst from a bot
The scraper uses up its burst allowance and is then told how long to wait. A denied request changes nothing.
GCRA.LIMIT ratelimit:bot:7 60000 10 - 03
Named limiter for a plan
Free-plan customers get 100 requests a minute on a sliding window.
RATELIMIT.CREATE free_plan 100 60000 ALGO sliding_window - 04
Weighted request
An export endpoint costs 20 units, so it uses more of the allowance.
RATELIMIT.CHECK free_plan customer:881 COST 20 - 05
See what the limiter did
Settings, tracked keys and the totals of allowed and denied requests.
RATELIMIT.STATS free_plan
Where it fits
Real-world scenarios
Login and signup forms
Attempts per IP and per account are limited to slow down credential stuffing.
Outbound calls
Calls to a partner API or an LLM provider are kept under their quota across every worker in the fleet.
Built in
What you get
GCRA in one command
Smooth refill with bursts, atomic check and update, a retry time on denial.
GCRA.LIMITGCRA.RESETNamed limiters
Sliding window, token bucket or leaky bucket, created once and checked per key.
RATELIMIT.CREATERATELIMIT.CHECKWeighted requests
Expensive calls can count as several requests. GCRA.LIMIT takes a count, RATELIMIT.CHECK a COST.
COSTStatistics
Allowed and denied totals per limiter.
RATELIMIT.STATSCommon questions
Do I need a Lua script for rate limiting?
No. Both GCRA.LIMIT and RATELIMIT.CHECK do the whole check as one atomic command.
Which should I use?
GCRA.LIMIT needs no setup and works on every plan. RATELIMIT.* named limiters add a choice of algorithm and statistics, and are part of the Performance and Scale plans.
What does a denied request cost?
Nothing. A denied GCRA call leaves the limiter unchanged, so a client that retries is not penalised further.
Related use cases
Try it on your own workload
HotKV speaks the Redis protocol, so you can point an existing client at it and run these same commands.