Cache TTL Hit Rate Calculator

TTL window visual unavailable.

Cache name:

Name the one cache population represented by these inputs.

Requests per minute:

Count only requests that can reach this cache population.

req/min

Unique keys per minute:

Use the keys the cache actually sees after normalization.

keys/min

TTL:

Use the freshness window being considered for this rule.

min

Target hit rate:

Targets at or above the post-invalidation ceiling are reported as unreachable.

TTL behavior:

Most HTTP and CDN freshness rules are closer to fixed expiry.

Fixed expiry Sliding expiry

Origin change interval:

The guardrail compares this cadence with the TTL window.

min

Invalidation penalty:

Leave at zero when this loss is already reflected in the request inputs.

Origin latency:

Use a comparable average for both origin and cache paths.

Cache latency:

Cache latency must not exceed the entered origin latency.

Key fragmentation:

Use zero for the measured base case.

Measure	Value	Operational meaning	Copy
{{ row.label }}	{{ row.value }}	{{ row.detail }}

TTL	Effective hit rate	Origin pulls	Blended latency	Freshness exposure	Copy
{{ minutes(row.ttl_minutes) }}	{{ percent(row.effective_hit_rate_pct) }}	{{ integer(row.origin_requests_per_minute) }} req/min	{{ decimal(row.blended_latency_ms, 0) }} ms	{{ percent(row.freshness_exposure_pct) }}

Guardrail	Current reading	Decision	Next check	Copy
{{ row.label }}	{{ row.value }}	{{ row.decision }}	{{ row.action }}

A cache saves work only when later requests ask for the same reusable object while its stored response is still acceptable. A long time to live (TTL) gives popular keys more opportunities to hit, but it can also keep changed content available for longer. A short TTL favors freshness and sends more requests back to the origin.

Hit rate depends on reuse per cache key, not traffic alone. Twelve thousand requests spread across a few stable keys can cache well; the same traffic split by user, locale, query string, device, or tenant may create thousands of distinct keys and far fewer repeats. Purges and other invalidations further reduce the hits that survive long enough to be served.

Fixed expiry: An object's expiry time is set when it enters the cache and does not move when the object is read.
Sliding expiry: A qualifying read refreshes the expiry window, so frequently reused objects can remain cached.
Invalidation: An early removal or bypass that cuts the usable hit rate below its theoretical level.
Freshness exposure: A planning indicator that combines TTL length, origin-change cadence, and the share of requests served from cache.

A modeled hit rate is a design hypothesis. It cannot discover uncacheable responses, uneven key popularity, request bursts, revalidation behavior, eviction under memory pressure, or an incorrect cache key. Production cache logs remain the final check before changing a live freshness policy.

How to Use This Tool:

Model one cache population whose requests share the same key and freshness rules.

Enter Requests per minute and the Unique keys per minute that the cache sees after normalization. Use Key fragmentation stress to test growth in the effective key count.
Enter the proposed TTL and choose Fixed expiry or Sliding expiry. Most HTTP and CDN freshness policies are closer to fixed expiry.
Set the Origin change interval and any separate Invalidation penalty. Leave the penalty at zero when purge or bypass loss is already reflected in the traffic inputs.
Enter comparable Origin latency and Cache latency, then set a Target hit rate.
Review target reachability, origin requests, blended latency, and freshness status together. If the target is blocked by the post-invalidation ceiling, lower the target or reduce the loss assumption.

Interpreting Results:

Theoretical hit rate comes from request reuse and TTL mode. Effective hit rate applies the entered invalidation loss, and it drives estimated origin load and blended latency. If the target is at or above the post-invalidation ceiling, no finite TTL can reach it in this model.

Freshness exposure interpretation
Exposure	Status	Reading
Below 35%	Freshness steady	The modeled cache share and TTL stay low relative to origin-change cadence.
35% to below 70%	Freshness watch	Compare the TTL with update and purge behavior before extending it.
70% or more	High freshness pressure	A long TTL, frequent origin changes, or a high hit share raises stale-content risk.

Latency savings uses the entered average cache and origin times; it does not include queueing, payload size, geographic variation, or revalidation cost. Confirm the direction and scale with observed percentiles rather than treating the modeled average as a service-level guarantee.

Technical Details:

This is a repository-authored Poisson reuse model. It assumes requests arrive independently and distributes them evenly across the effective key population. Fixed and sliding expiry use different reuse curves, then the same invalidation, origin-load, latency, and freshness calculations.

Formula Core

Key fragmentation first increases unique keys K by stress percentage s. Reuse rate λ is then requests R divided by effective keys, measured in requests per key per minute.

\begin{array}{l} K_{e} = K (1 + \frac{s}{100}) \\ λ = \frac{R}{K_{e}} \end{array}

For TTL t in minutes, fixed expiry uses a renewal ratio and sliding expiry uses the probability of at least one reuse during the window.

\begin{array}{l} H_{fixed} = \frac{λ t}{1 + λ t} \\ H_{sliding} = 1 - e^{- λ t} \end{array}

Invalidation penalty p reduces the theoretical ratio H. Effective hit rate H_e determines origin volume and average latency L.

\begin{array}{l} H_{e} = H (1 - \frac{p}{100}) \\ R_{origin} = R (1 - H_{e}) \\ L = H_{e} L_{cache} + (1 - H_{e}) L_{origin} \end{array}

Freshness exposure E is capped at 100%. It is the TTL-to-change-interval ratio multiplied by effective hit rate.

E = \min (100, \frac{t}{c} \times 100 \times H_{e})

Rule Core

The largest possible effective hit rate is 1 − p/100. A target equal to that ceiling is blocked because both reuse curves approach 100% theoretical hit rate without reaching it at a finite TTL. Targets below the ceiling are inverted to find the required TTL.

\begin{array}{l} t_{fixed} = \frac{H_{t}}{(1 - H_{t}) λ} \\ t_{sliding} = \frac{- \ln (1 - H_{t})}{λ} \end{array}

Here H_t is the requested effective target divided by the available post-invalidation share. With 12,000 requests per minute, 1,800 keys per minute, a 15-minute fixed TTL, and 5% invalidation loss, the model returns about 94.06% effective hits, 712.87 origin requests per minute, 45.99 milliseconds blended latency, and 23.51% freshness exposure. A 90% target needs about 2.7 minutes under the same assumptions.

Requests and unique keys must each be at least 0.01 per minute. TTL accepts 0 to 525,600 minutes, target hit rate 0% to 99.9%, invalidation loss 0% to 100%, and key-fragmentation stress 0% to 200%. Cache and origin latency must be non-negative, and cache latency cannot exceed origin latency.

Model Limits:

The formulas estimate a steady average, not the behavior of a particular cache product or traffic trace.

Key popularity is treated as uniform, so hot keys and a long cold tail are not represented.
Capacity eviction, cache fill after deployment, revalidation, conditional requests, bypass rules, and response cacheability are outside the model.
Fixed and sliding modes describe expiry policies; they do not override HTTP cache-control directives or application-specific invalidation rules.

References:

RFC 9111: HTTP Caching, Internet Engineering Task Force, June 2022.
How to enable caching in Nginx, Simplified Guide.