Fallback and Disaster Recovery Strategies for High‑Traffic Web Pages

With the rapid growth of internet usage, web pages now handle tens of millions of daily visits, and data sources can be unstable or manually maintained, increasing the risk of failures under heavy load. To reduce maintenance costs and ensure a smooth user experience, the article discusses the necessity of fallback ("兜底") and disaster‑recovery strategies.

Why fallback is needed

If an API endpoint crashes, the front‑end may receive no data, resulting in blank sections or "sky‑window" errors.

Network issues or browser plugins can cause request failures for a small fraction of users; on a site with 100 million page views, even a 0.1% failure rate translates to tens of thousands of failed requests per day.

Common fallback solutions

1. Retry the request

Set a timeout (e.g., 5 seconds) and, if the request fails, automatically retry once. This works well for critical actions like order submission or adding items to a cart.

// Set request attempts
var tryTimes = 2;
Ajax({
url: url,
timeout: 5000,
dataType: "jsonp",
tryTimes: tryTimes
});

2. Cache each successful request locally

Store the response in localStorage (or similar) so that if a subsequent request fails, the page can fall back to the cached data.

Ajax({
url: url,
dataType: "jsonp",
success: function(data){
// Cache data locally
cache(DATAKEY, data);
show(data);
},
error: function(){
// Retrieve cached data on failure
var data = cache(DATAKEY);
show(data);
}
});

Issues to consider: first‑time visitors may have no cache, and cached data may become stale (e.g., outdated recommendations).

3. Backup (hard) interface

Provide an alternative URL that returns a generic or pre‑generated dataset when the primary API fails.

Ajax({
url: url,
backUrl: backUrl
});

For personalized data, a hard backup may need to serve generic content; otherwise, the fallback is less useful.

Practical workflow

The author proposes a closed‑loop process: each front‑end request first tries the primary API, falls back to a cached version, then to a backup interface, and finally to a manually curated dataset supplied by operations. All data is also pushed to a CDN for redundancy.

Improvements include monitoring, alerting, and ensuring cache expiration (e.g., 10 days) to keep data reasonably fresh.

Below is a representative pseudo‑code implementation of the entire fallback logic:

var url = interfaceURL;
var backUrl = interfaceBackURL;
var hardBackUrl = hardDataURL;
var cacheTime = 10day;
Ajax({
url: url,
backurl: backUrl,
success: function(){
cache(DATAKEY, data, cacheTime);
show(data);
},
error: function(){
var data = cache(DATAKEY);
if(data) {
Reporter.send(/*WARN*/);
show(data);
} else {
Reporter.send(/*ERROR*/);
_failed();
}
}
});
// Hard fallback
function _failed() {
Ajax({
url: hardBackUrl,
success: function(data){
cache(DATAKEY, data, cacheTime);
show(data);
},
error: function(){
Reporter.send(/*SUPER_ERROR*/);
show(data);
}
});
}

By combining retry, local cache, CDN‑backed backup, and manually curated fallback data, the probability of a visible "sky‑window" is dramatically reduced, allowing developers to rely on monitoring and alerts rather than frantic emergency fixes.

Conclusion

The article provides straightforward pseudo‑code and design ideas for handling asynchronous data requests under high traffic and concurrency, encouraging readers to share their own improvements.