How to Build Robust Fallbacks for High‑Traffic Front‑End Pages

Why Fallbacks Are Essential

Taobao’s homepage receives about 100 million page views per day, with most data loaded via API calls to various backend systems that have differing stability. When a single API fails, the page can show blank sections or “sky‑window” errors, potentially escalating into a major PR incident due to the massive traffic.

Even a tiny fraction of users (≈0.1 %) experiencing network or plugin problems can generate around 100 k failed requests per day, and the total failed requests can reach millions.

Common Fallback Strategies

1. Retry Once

Set a timeout (e.g., 5 seconds); if the request fails or times out, automatically retry once. This works well for critical actions like order submission.

var tryTimes = 2;
io({
  url: url,
  timeout: 5000,
  dataType: "jsonp",
  tryTimes: tryTimes
});

2. Cache Responses Locally

Store each successful response in localStorage (or other browser storage). If a subsequent request fails, retrieve the cached data.

io({
  url: url,
  dataType: "jsonp",
  success: function(data) {
    cache(DATAKEY, data);
    show(data);
  },
  error: function() {
    var data = cache(DATAKEY);
    show(data);
  }
});

Considerations: first‑time failures for new users and data staleness (e.g., outdated recommendations).

3. Backup Interface (Hard Fallback)

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

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

If the backup data is personalized, additional logic is required; otherwise, a simple second request may suffice.

Practical Implementation and Improvements

Typical flow diagrams (shown below) illustrate the basic fallback process, but they expose issues such as inability to validate cached data, stale fallback data, and lack of automatic repair.

To address these, a unified platform pushes data to a CDN as a backup before serving it. If the primary API fails, the system automatically requests the CDN backup, ensuring up‑to‑date data and reducing manual intervention.

Additionally, each interface has an operation‑filled static dataset stored in the CDN as a final hard fallback, which is also cached locally, forming a closed loop with monitoring and alerts.

Sample pseudo‑code for the complete flow:

var url = interfaceURL;
var backUrl = interfaceBackURL;
var hardBackUrl = hardDataURL;
var cacheTime = 10; // days
io({
  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();
    }
  }
});
function _failed() {
  io({
    url: hardBackUrl,
    success: function(data) {
      cache(DATAKEY, data, cacheTime);
      show(data);
    },
    error: function() {
      Reporter.send(/*SUPER_ERROR*/);
      show(data);
    }
  });
}

The cache expiration is set to 10 days to balance freshness and availability. With this architecture, even if the primary backend fails, the front‑end can gracefully degrade, alert the operations team, and continue serving users.

Conclusion

The provided pseudo‑code is simple yet effective, offering a clear mindset for handling asynchronous data interfaces under massive traffic and high concurrency without needing complex components.