Choose Cache Boundaries before Choosing Cache Duration

A practical approach

Step 1

List every input that affects the response and classify the content as public, user-specific or access-sensitive.

Step 2

Choose a cache location and key that preserve those boundaries. Keep personalized content out of shared caches unless the design explicitly supports it safely.

Step 3

Test invalidation and cross-user behaviour as well as hit rate. A fast wrong or unauthorized response is still a failure.

Worked example

Public course descriptions can often share cached responses, while a learner’s completion status depends on their identity. Combining both into one shared cached page without a correct boundary can expose one learner’s progress to another.

A mistake to avoid

A short expiration time does not make an incorrectly shared response safe. Also consider cached errors and redirects; they can preserve a temporary problem longer than expected.

Try it yourself

Choose one endpoint and write its cache key on paper. Change each input in turn—user, language, filters and content version—and decide whether reuse is still valid.

Your implementation checklist

• Response dependencies are explicit.
• Personalized data has a safe boundary.
• Invalidation is tested.
• Errors and redirects have deliberate policies.