Guides
  1. Best Practices

Caching Best Practices

Recommended caching patterns for improving performance while preserving freshness, personalization, and operational control.

Caching Best Practices

Caching is one of the highest-impact performance tools available in a Nomad Media integration, but it works best when applied deliberately. The goal is to improve response time and scale without breaking personalization, freshness, or time-sensitive publishing behavior.

For Nomad Media-specific cached URL behavior, see API URLs and Caching.

1. Cache as Close to the User as Possible

As a general rule, caching should happen at the outermost layer that can safely serve the response. In most architectures, that means starting with the CDN or edge cache before moving deeper into the application stack.

  • Prefer CDN or edge caching first
  • If full page caching is not possible, cache API responses
  • Only move caching deeper into the application when outer layers cannot safely do the job

This approach reduces latency, offloads origin traffic, and usually provides the best scalability.

2. Cache Stable GET Responses, Not Mutations

Cacheable traffic is usually read traffic. In practice, this means GET requests are the best candidates for caching, while login flows and write operations should pass through uncached.

  • Good candidates: content lists, landing page data, category pages, lookup-style requests
  • Poor candidates: login, account changes, writes, workflow actions, and most POST-based operations

If a response needs caching, prefer an API design that exposes the retrieval as a GET request.

3. Separate Shared and Personalized Data

Many pages combine two very different kinds of data:

  1. Shared content that is the same for most users
  2. Personalized content that depends on the current user or role

Do not force both through the same cache strategy. Instead:

  • Keep broadly shared page data in one cacheable API response
  • Move personalized sections into separate requests
  • Apply a different TTL, keying strategy, or no caching at all for user-specific data

This pattern preserves a high cache hit rate while still supporting role-based or user-specific experiences.

4. Use Short TTLs for Frequently Changing Content

When content changes throughout the day, a short cache window often gives the best balance between freshness and performance. A TTL in the low-minute range is commonly enough to absorb most traffic while keeping content acceptably current.

Short TTLs are especially useful for:

  • rotating homepage sections
  • newly published or unpublished content
  • schedule-driven visibility such as sunrise and sunset dates

Choose the TTL based on business tolerance. If a 3-to-5-minute delay is acceptable, you can usually gain most of the performance benefit without operational complexity.

5. Handle Time-Sensitive Content Explicitly

Schedule-driven content creates a tradeoff: longer caching improves performance, but exact-minute publishing becomes harder.

Two common patterns work well:

  • Short TTL approach: keep the cache window small so scheduled changes appear within a few minutes
  • Hybrid approach: return the schedule metadata in the response and let the client perform a final visibility check at render time

The hybrid approach can support more exact display timing, but it may send some data that will be hidden on the client until the cache refreshes.

6. Accept That Not Everything Should Be Cached

Some requests are naturally poor cache candidates, especially highly variable or user-driven queries such as ad hoc search and complex filtering. That is normal.

Instead of trying to cache every request:

  • focus first on high-volume, repeatable reads
  • leave uncommon or highly variable requests uncached when needed
  • revisit deeper caching patterns only after the primary traffic is optimized

The goal is not 100% cache coverage. The goal is meaningful load reduction and faster common paths.

7. Design for Cache Invalidation

Even with well-chosen TTLs, you should still plan for cases where content must be refreshed immediately.

Recommended practices:

  • confirm which layer owns the cache
  • document how to invalidate or purge it
  • identify the routes or content types that may need urgent refreshes
  • test the invalidation path before production launch

Manual invalidation is especially important for time-sensitive campaigns, urgent content corrections, and externally visible mistakes.

8. Validate Both Development and Production Paths

Development often uses live uncached responses for fast iteration, while production should use the cached path. Validate both behaviors during implementation.

Before launch, confirm that:

  • uncached development requests still behave correctly
  • cached production requests return the expected data
  • personalized requests are not accidentally shared across users
  • non-cacheable methods bypass caching as intended

9. Practical Decision Framework

When deciding where and how to cache, use this order of operations:

  1. Cache at the CDN or edge when possible
  2. Cache shared GET responses before personalized ones
  3. Keep dynamic or schedule-sensitive responses on short TTLs
  4. Avoid caching writes and login flows
  5. Add invalidation controls for urgent refresh scenarios

Following this sequence usually produces the best balance of speed, scale, and correctness.