Skip to content

Redis

Redis holds data in memory so an app can quickly reuse a result or keep a shared count across servers.

Visit Redis

What should you put in Redis first?

Start with a result that takes work to produce and can be safely rebuilt, such as a public list of upcoming classes. Keep the official schedule in your app’s main database. Redis can hold a short-lived copy for the server to reuse.

Set an expiry, sometimes called a time to live or TTL. Decide whether changing a class should clear its cached copy right away. When a copy has expired or been removed to free memory, the app needs to fetch the current schedule again.

Can Redis limit requests on its own?

Redis can hold a shared counter for your app’s servers. Your app still decides who shares a counter, when it resets and what to do at the limit. Keep counters separate from cached pages. If counters disappear when the cache runs out of room, the app may allow more requests than you intended.

Agree on what happens if the counter store is unavailable. You might pause an action that can trigger a charge while keeping the public schedule readable.

What changes if you run Redis yourself?

Redis Open Source is available to run yourself. You supply the machine, access controls, updates and monitoring. Redis Cloud also lists a shared Free plan with one database up to 30 MB. Check memory and retention needs before choosing either.

For a disposable cache, keep the key naming, expiry and invalidation rules in the app so a new cache can start empty. A move that includes counters needs an explicit reset or continuity plan. This exercise treats Redis as a copy store, with the original records held elsewhere.

What should happen when a cached schedule disappears?

Draw a fictional public schedule and its copy on paper. Use no live traffic or customer information.

  1. Show a cache hit
    Draw a second read before the copy expires. It can reuse the public schedule without fetching the original again.
  2. Change a class
    Update the original and cross out the old copy. The next read should fetch the changed schedule and can make a fresh copy.
  3. Remove the copy
    Cross out the new copy too. The next read should still work from the original. This tests the plan on paper. Actual Redis behavior remains untested.