Do you need to reuse a result or limit an action?
Use a cache when many visitors can safely reuse the same result. Use a request limit when someone can repeat an action faster than your app or budget can handle. A public schedule and a paid email reminder can need different rules.
Which work can you safely reuse?
Start with a public result, such as a class list that everyone can see. Keep the original in its usual home and give the copy a time limit. If a class cancellation needs to show up right away, clear the old copy when you save the change.
Keep private bookings out of a shared page cache. A broad rule can override normal caching behavior, so check what the rule applies to before expanding it.
What should happen after someone reaches a limit?
Choose one action, such as sending a reminder, and decide who gets the allowance and when it resets. A shared network address can represent several people, so an app can often make a better decision after sign-in using the account it already knows.
Give the person a clear next step if the action is paused. Treat a request limit as one control. Your app still needs to decide who is allowed to send the reminder.
Compare tools
Scroll the table sideways to read every column.
| Tool | Where does it fit?Which part of your app it helps. | What can you reuse?Where the copy lives and how it stays current. | How do you limit requests?Who enforces the limit and which plan details matter. | What should survive a move?The decisions and data to keep if you replace the tool. |
|---|---|---|---|---|
| Upstash | Use a managed Redis database for reusable results or app-side counters. | The app stores selected results with an expiry. An Upstash library can evaluate request limits. | Your server applies the library’s decision. A limiter timeout can allow a request. Count Redis operations for the chosen plan. | Keep the app’s cache and limiter rules. Plan what happens to active counters on a move. |
| Redis | Run Redis yourself or choose Redis Cloud for a reusable copy or a shared counter. | The app decides what to copy and when to expire it. Memory rules can remove entries earlier. | Your app implements the request decision. Cloud Free lists one shared database up to 30 MB. | Rebuild disposable entries from the source. Review active counters separately. |
| Cloudflare | Cache eligible site responses near visitors or limit traffic that passes through Cloudflare. | Eligible public files can be reused. Check response headers and Cache Rules before caching other responses. | Free lists one rule that counts by network address. Use app-level checks for an exact account allowance. | Keep cache eligibility and request rules documented. The original responses still come from your site. |
| Arcjet | Check requests at a chosen endpoint in your app. | This is a request rule. Use a separate cache for reusable results. | Choose whose requests count together and try dry-run mode. Compare plan and request fees. | Keep the identity, endpoint, window and retry behavior. |
| Unkey | Give API customers keys and define how calls are counted. | Use this for API access and allowances. Cache response data separately if needed. | Choose per-key or shared per-customer limits. Compare the meter for your integration. | Keep customer-to-key ownership and permission rules. Plan replacement keys if needed. |
| Valkey | Run a BSD-licensed in-memory data store or choose a managed host. | Save short-lived copies your app can refill. Choose persistence when needed. | The app supplies the counting and retry rule. Budget for memory and operations. | Keep refill code and verify backups if the data must survive. |
| Amazon ElastiCache | Choose an AWS-managed Valkey, Redis OSS or Memcached engine. | Keep reusable app results in a cache the backend can reach. | Enforce request limits separately. Compare Serverless storage and processing with running nodes. | Keep the engine and app settings, plus any required restore path. |
| Google Cloud Memorystore | Choose a Google Cloud-managed cache and engine. | Connect your app server. For Valkey, check cluster mode and the client. | Enforce request limits separately. Valkey charges for provisioned capacity and may have other fees. | Keep network settings, app commands and a way to refill or restore. |
| Dragonfly | Compare a self-hosted in-memory store with Dragonfly Cloud. | Check your current cache commands, data types and expiration before switching. | The app still decides which requests to allow. Check self-host licensing and cloud pricing separately. | Keep a way to refill or restore. Verify compatibility for your exact version. |
| Garnet | Operate the MIT-licensed cache from Microsoft Research. | Use supported Redis protocol commands. Check client and command behavior. | Request policy belongs in the app or a separate service. Budget for infrastructure. | Keep client settings, expected commands and recovery configuration. |
How can you check both rules before connecting services?
On paper, draw a fictional public class schedule and a reminder action. Leave out real data and do not send requests.
- Change the public scheduleMark a class cancelled in the original. Draw the next read retrieving the new schedule after you clear the copy.
- Give two fictional accounts separate allowancesMark a reminder for the first account, then another after its paper allowance is spent. The second reminder should be paused, while the other account still has its allowance.
- Remove a dependencyCross out the copy store and see whether the schedule can still be read. Cross out the counter store separately and write what should happen to reminders. Real traffic and service behavior remain untested.