Fallback cache logic

The fallback cache keeps applications usable during transient Optimizely Graph backend failures by returning the most recent successful response for the same resource. Use the fallback cache to absorb 5xx responses and network timeouts so end users see continuity instead of an error page while the backend recovers.

How fallback cache logic works

This section explains the storage and retrieval path so integrators can predict what the cache returns under each backend condition. When the backend returns a successful response, the system stores the response in the fallback cache. Each cached entry includes metadata such as a Last-Modified header, which indicates when the data was last updated.

If a subsequent request to the same resource fails because of a server error or timeout, the system checks the fallback cache and returns a valid cached response when available. If no cached response exists, the system returns the original error response.

The Last-Modified header included in the cached response helps clients determine the freshness of the data, which lets the UI display fallback notifications (for example, a banner that the data may be stale).

Caching criteria

The caching criteria define which responses the system stores and which it skips, so integrators can predict whether a given request becomes a fallback candidate.

• The system stores only responses that meet internal caching criteria.
• The system does not cache responses in the following cases:
  • The request includes the query parameter cache=false.
  • The request includes the header Cache-Control: no-cache.

Fallback restrictions

Responses served from the fallback cache come with restrictions that protect data integrity while the backend is unavailable.

• Responses served from the fallback cache are read-only.
• You cannot make updates or deletions while operating in fallback mode.

Benefits of fallback cache logic

The fallback cache delivers three operational benefits that justify enabling it in production environments.

• Improves reliability during backend outages.
• Reduces visible service interruptions.
• Delivers the most recent available data, even when the backend is unavailable.

📘

Note

Always validate the Last-Modified timestamp before assuming the returned data is current. Do not use the fallback cache as a substitute for proper error handling or data freshness requirements.

Response example

A cached fallback response includes a Last-Modified header, as shown in the following snippet.

HTTP/1.1 200 OK
Content-Type: application/json
Last-Modified: 2025-07-28T10:15:00.000Z