Skip to main content
A cache reuses an earlier result; a rate limit controls how often an action is accepted. They solve different problems. Both need explicit keys, bounds, and failure behavior.

A short-lived local cache

This example caps entry count and expires values on read. It uses insertion-order eviction, not a full least-recently-used algorithm. It does not bound the byte size of values, coordinate concurrent fills, or survive a process restart. Only cache small public values with a known policy.

Rate-limit decisions

A fixed-window limiter counts accepted attempts for a key during one interval. Choose the key and interval based on the action. An IP address can be shared by many people; an email address is personal data. Do not trust an arbitrary forwarded-IP header unless your deployment’s trusted proxy establishes it. The downloadable recipe module includes a bounded, process-local fixed-window example. Use it to study expiry and test boundaries, not as distributed abuse protection. Multiple server instances each have their own count; restarting a process resets it. A shared store needs atomic operations and a deliberate failure policy. Capacity eviction also resets an evicted key’s allowance, so a stream of new keys can weaken this example. It is intentionally unsuitable as a security boundary.

Safe production boundaries

Do not publicly cache authentication, private profile data, confirmation tokens, Set-Cookie responses, or mutations. Avoid storing errors as successful values. For costly or sensitive actions, decide whether a limiter outage rejects the action or permits a limited fallback. Neither behavior is universally correct. Test expiry, an exact limit boundary, independent keys, and the chosen eviction behavior. Read AVRXT’s cache policy for the actual shared Worker design, and download the learning module for runnable examples.