Free calculator · Engineering

Plan Redis capacity for API rate limits and caching

Enter your peak traffic, cacheable share, hit ratio and rate-limit policy. The planner shows the load left on your origin, the Redis throughput and shards you need, cache and limiter memory, and how one client is treated under fixed window, sliding window or token bucket limits.

How this is calculated Related service: Custom software

API rate-limit and caching capacity planner

Enter your peak traffic, how much of it a cache can answer and your rate-limit policy. The planner works out the load left on your origin and the Redis throughput and memory the limiter and cache need.

Traffic

Peak requests per second

Origin capacity (requests per second)

From a load test of your app servers and database. Enter 0 if you don't know it.

Cacheable requests (%)

Responses a cache may store and reuse (RFC 9111).

Cache hit ratio (%)

Share of cacheable requests the cache answers.

Rate limiting

Requests over the limit get a 429 Too Many Requests response (RFC 6585); the RateLimit header draft describes how to tell clients their quota.

Clients with a live limiter key

API keys, users or IP addresses active within one window.

Algorithm

Each follows Redis's reference implementations.

Fixed windowOne counter per window. Allows up to twice the limit across a boundary.Sliding window counterWeights the previous window's count. Close to exact, two keys per client.Sliding window logLogs every request in a sorted set. Exact, but memory grows with the limit.Token bucketAllows a burst up to the bucket size, then the refill rate.

Bucket size, B (requests)

Refill rate, r (per second)

One client's burst rate, d (per second)

Horizon, T (seconds)

Cache contents

Hot objects kept in memory

Copies (primary plus replicas)

Average key size (bytes)

Average value size (bytes)

Adjust assumptions

Redis sizing

Measure your own keys with MEMORY USAGE and your own throughput with redis-benchmark.

Commands per second per shard

Headroom kept free (%)

Overhead per cached key (bytes)

Fragmentation over data size (%)

mem_fragmentation_ratio from INFO memory, minus 1 (Redis).

Bytes per limiter key

Bytes per sliding-log entry

Redis commands per limiter check

Fixed window

Sliding window counter

Sliding window log

Token bucket

Capacity plan

Requests reaching the origin at peak

810/s

The cache answers 59.5% of 2,000/s.

Under 25% spare at the origin

81% of the 1,000/s your origin handles.

Redis

Commands per second at peak: 7,400/s; 6,000/s for rate limiting (3 per check) and 1,400/s for cache reads.
Shards for that throughput: 1; At 50,000/s per shard with 25% kept free.
Cache memory to provision: 3.31 GiB; 1.03 GiB of data, with fragmentation, 2 copies and headroom.
Rate-limit memory (token bucket): 4.77 MiB; 100 B per client, one copy, before fragmentation and headroom.

One client under this policy

Sustained rate: 5/s
Most one client can send in 60 s: 320; A full bucket of 20, plus 5/s refill.
Bucket runs dry at 10/s: after 4 s; After that the client is held to the refill rate and extra requests get 429 responses.

Not in this plan: cache writes on misses, TTL expiry and eviction, network bandwidth, client connection counts, and Redis persistence. Treat shard counts as a starting point for a load test.

How this is calculated

The planner works from your peak requests per second. The cache answers the cacheable share at your hit ratio, and the rest reaches the origin. Rate limiting adds Redis commands for every request, cache reads add one for every cacheable request, and memory comes from key and value sizes with Redis's per-key overhead, fragmentation, copies and headroom.

Step by step

Origin load: peak requests per second × (1 − cacheable share × hit ratio). Compared with the origin capacity you enter, when you enter one.
Redis commands per second: peak requests per second × commands per limiter check for the chosen algorithm, plus peak requests per second × cacheable share for cache reads.
Shards: commands per second ÷ (commands per shard × (1 − headroom)), rounded up.
Cache memory: hot objects × (key + value + per-key overhead) × (1 + fragmentation) × copies ÷ (1 − headroom).
Rate-limit memory: clients × bytes per client. A fixed window or token bucket keeps one key per client, a sliding window counter two, and a sliding window log one key plus up to N entries.
Token bucket: a client can send B + r × T requests in T seconds, and a client sending d requests a second (faster than r) empties the bucket after B ÷ (d − r) seconds.
Fixed window: the worst burst across a window boundary is 2N, because a client can spend the whole limit at the end of one window and again at the start of the next.

Default assumptions

Assumptions marked adjustable can be changed in the calculator; the others are fixed parts of the model.

Default assumptions and their sources
Assumption	Default	Sources
Peak requests per secondadjustable	2,000 a second	None
Share of requests that are cacheableadjustable	70%	[7]
Cache hit ratioadjustable	85%	None
Origin capacityadjustable	1,000 a second	None
Clients with a live limiter keyadjustable	50,000 clients	None
Window limit (N requests)adjustable	100 requests	None
Window length (W)adjustable	60 seconds	None
Token bucket capacity (B)adjustable	20 requests	[8]
Token refill rate (r)adjustable	5 a second	[8]
One client's burst rate (d)adjustable	10 a second	None
Horizon for allowed requests (T)adjustable	60 seconds	None
Bytes per limiter keyadjustable	100 bytes	[2]
Bytes per sliding-log entryadjustable	64 bytes	[3] [2]
Redis commands per check: fixed windowadjustable	2 commands	[1]
Redis commands per check: sliding window counteradjustable	3 commands	[1] [9]
Redis commands per check: sliding window logadjustable	4 commands	[1]
Redis commands per check: token bucketadjustable	3 commands	[1]
Sustained commands per second per Redis shardadjustable	50,000 a second	[4]
Headroom kept freeadjustable	25%	[3]
Hot objects in the cacheadjustable	1,000,000 objects	None
Average cache key sizeadjustable	50 bytes	None
Average cached value sizeadjustable	1,000 bytes	None
Redis overhead per cached keyadjustable	60 bytes	[2]
Memory fragmentation over data sizeadjustable	20%	[3]
Copies of the cache (primary plus replicas)adjustable	2 copies	None
Live keys per client: fixed window	1 key	[1]
Live keys per client: sliding window counter	2 keys	[1] [9]
Live keys per client: token bucket	1 key	[1]
Worst burst across a fixed-window boundary	2× the limit	[1] [9]

What this doesn’t model

Cache writes on misses, TTL expiry, eviction and key churn aren't counted in Redis commands or memory.
Rate-limit memory is one copy, before fragmentation, replicas and headroom; apply the same factors as the cache if the limiter shares its cluster.
Redis throughput varies with CPU, network, virtualisation, connection count, pipelining and the cost of Lua scripts. The shard count is a starting point for a load test, not a result of one.
Network bandwidth between clients, Redis and the origin isn't modelled.
Traffic is treated as a steady peak; real traffic arrives in bursts, and hit ratios fall after deploys and cache flushes.
The sliding window counter is an approximation; it can let slightly more or fewer requests through than the limit.

Sources

Redis, Build 5 rate limiters with Redis: fixed window, sliding window, token bucket, and leaky bucket (26 Feb 2026). Accessed 9 Oct 2026. Lua scripts per algorithm: fixed window INCR, EXPIRE and PTTL on one key; sliding counter two GETs and an INCR across two keys; sliding log ZREMRANGEBYSCORE, ZCARD, ZADD and EXPIRE on a sorted set; token bucket HGETALL, HSET and EXPIRE on one hash. Fixed windows allow up to twice the limit across a boundary.
Redis, MEMORY USAGE. Accessed 9 Oct 2026. Reports the bytes a key and its value take in RAM, including administrative overhead; an empty string key measures 56 bytes on Redis 7.2 (64-bit, jemalloc).
Redis, Memory optimization. Accessed 9 Oct 2026. Small sorted sets (128 entries or fewer by default) use a compact encoding; provision memory for peak usage; fragmentation ratio is RSS divided by memory in use.
Redis, Redis benchmark. Accessed 9 Oct 2026. Example runs: 180,180 SET/s on one key and 72,144 SET/s over 100,000 random keys, without pipelining; results depend on CPU, network, virtualisation and connection count.
IETF, RFC 6585: Additional HTTP status codes (section 4, 429 Too Many Requests) (Apr 2012). Accessed 9 Oct 2026. 429 means the user sent too many requests in a given amount of time; the response may include Retry-After.
IETF HTTPAPI working group, RateLimit header fields for HTTP (draft-ietf-httpapi-ratelimit-headers-11) (23 May 2026). Accessed 9 Oct 2026. An active Internet-Draft, not yet an RFC, defining the RateLimit-Policy and RateLimit fields.
IETF, RFC 9111: HTTP caching (Jun 2022). Accessed 9 Oct 2026. Which responses a cache may store and when a stored response is fresh enough to reuse.
Stripe, Scaling your API with rate limiters (30 Mar 2017). Accessed 9 Oct 2026. Stripe's request rate limiter uses the token bucket algorithm, implemented with Redis.
Cloudflare, How we built rate limiting capable of scaling to millions of domains (7 Jun 2017). Accessed 9 Oct 2026. Sliding window counter: previous count × (time left in the window ÷ window) + current count. Across 400 million requests, 0.003% were wrongly allowed or limited.

Last reviewed 9 Oct 2026 by the QuantmHill engineering team. Found an error?

Link to or cite this tool

Writing about this topic? Link to the calculator or cite it. Its method, defaults and sources are all on this page, so readers can check the numbers.

Page link

Citation

QuantmHill. (2026). API rate-limit and caching capacity planner [Online calculator]. Last reviewed 9 Oct 2026. https://quantmhill.com/tools/api-rate-limit-and-caching-capacity-planner

Embed this calculator

You can put this calculator on your own site for free. Paste the code below where it should appear. It loads the same calculator in a frame, with a link back to this page for the full method and sources.

Embed code

<iframe src="https://quantmhill.com/embed/tools/api-rate-limit-and-caching-capacity-planner" title="API rate-limit and caching capacity planner by QuantmHill" width="100%" height="1400" loading="lazy" style="border:0;max-width:960px"></iframe>
<p>Calculator by <a href="https://quantmhill.com/tools/api-rate-limit-and-caching-capacity-planner">QuantmHill</a></p>

The credit line links to this page with the anchor text “QuantmHill”. You may edit it, add rel="nofollow" or remove it — the calculator works the same either way. Add ?theme=light or ?theme=dark to the iframe address to fix its colour scheme; otherwise it follows the visitor's system setting.

Optional auto-height script

<script>
window.addEventListener("message", function (e) {
  if (e.origin !== "https://quantmhill.com") return;
  var d = e.data;
  if (!d || d.source !== "quantmhill-embed" || typeof d.height !== "number") return;
  var frames = document.querySelectorAll('iframe[src^="https://quantmhill.com/embed/"]');
  for (var i = 0; i < frames.length; i++) {
    if (frames[i].contentWindow === e.source) {
      frames[i].style.height = Math.min(4000, Math.max(200, Math.ceil(d.height))) + "px";
    }
  }
});
</script>

Add this once per page, after the iframe, if you want the frame to grow and shrink with the calculator instead of using the fixed height above. It accepts messages from quantmhill.com only and resizes only the frame that sent them.

Frequently asked questions

Five things: the requests per second that still reach your origin after caching, the Redis commands per second that rate limiting and cache reads add, the number of Redis shards for that throughput, the memory to provision for the cache, and the memory the rate limiter's keys take. It also shows how much one client can send under the policy you enter.

It depends on how strict you need to be. A fixed window is simplest but lets a client send up to twice the limit across a window boundary. A sliding window counter smooths that out with two keys per client; Cloudflare found its approximation wrong for 0.003% of 400 million requests. A sliding window log is exact but stores every request. A token bucket allows a burst up to the bucket size and then the refill rate; Stripe uses one for its request rate limiter.

Each limiter check runs the commands in Redis's reference scripts: two for a fixed window, three for a sliding window counter or token bucket, and four for a sliding window log. Each cacheable request adds one cache read. You can change every count under Adjust assumptions.

The default of 50,000 commands a second sits below the 72,144 SET commands a second shown on Redis's benchmark page for one instance over 100,000 random keys without pipelining. Your figure depends on the CPU, network, virtualisation, number of connections and Lua scripts, so benchmark your own instance type and enter that.

It is a sizing estimate. Redis reports 56 bytes for an empty string key on a 64-bit build, and real keys add their name and value length, so the defaults are close to a typical small key. Run MEMORY USAGE on a few of your own keys and read mem_fragmentation_ratio from INFO memory, then enter those figures.

HTTP status 429 Too Many Requests, defined in RFC 6585, optionally with a Retry-After header saying how long to wait. The IETF's RateLimit header fields draft, still an Internet-Draft, describes headers that tell clients their remaining quota.

Want an engineer to check your numbers?

Send us your inputs and the decision you're weighing. We'll reply within one business day with an honest read on whether we can help.

Talk to an engineer

Capacity plan

Redis

One client under this policy

How this is calculated

Step by step

Default assumptions

What this doesn’t model

Sources

Link to or cite this tool

Embed this calculator

Frequently asked questions

What does this planner work out?

Which rate-limiting algorithm should I use?

How is the number of Redis commands counted?

Where does the throughput per shard come from?

How accurate is the memory estimate?

What should an API return when a client is over the limit?

Want an engineer to check your numbers?

Capacity plan

Redis

One client under this policy