Fallback cache Logic

📘

Note

This is a feature-flagged feature.

The fallback cache enhances the resilience of your API requests by serving previously cached responses when the backend is unavailable or encounters an error. This helps maintain application stability and improves the user experience during backend outages or temporary failures.

As a secondary caching system, the fallback cache stores successful API responses. If a subsequent request for the same resource fails due to a backend error, the system returns the most recent cached version of the response, if available, instead of failing the request.

How fallback caching works

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 later request to the same resource fails, such as due to a server error or timeout, the system checks the fallback cache. If a valid cached response is available, it is returned to the client. 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. This enables UI strategies such as showing fallback notifications or marking the content as potentially stale.

Behavior and conditions

• The system stores only responses that meet internal caching criteria.
• Responses are not cached if:
  • The request includes the query parameter cache=false
  • The request includes the header Cache-Control: no-cache
• Responses served from the fallback cache are read-only. The system does not let you update or delete while operating in fallback mode.

Benefits of using Fallback cache logic

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

📘

Note

• Fallback cache responses are read-only. The system does not let users make updates or deletions while operating in fallback mode.
• Always validate the Last-Modified timestamp before assuming the returned data is current.
• Fallback cache should not be used 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 example:

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