How an External Resource Manager Boosts Service Resilience with Multi‑Layer Caching

1. Basic Principle

At Weimob, to ensure the stability of overseas e‑commerce (ShopExpress) services, an External Resource Manager was built to manage external dependencies, cache results, and enhance service robustness without altering returned data.

2. Access Methods

The manager supports two domain patterns:

*.{{customDomain}}.com – public CDN domain supporting HTTP/HTTPS with cache durations from 1 second up to 1 year (e.g., long‑term font files).

*.internal.shopexpress.com – internal domain supporting HTTP only, without CDN caching (some services use local cache first).

Requests can be identified as new by checking the globalticket or beijingtime headers.

3. Detailed Explanation

1. Cache Mechanism

Three cache layers are used:

CDN cache

Local memory cache

Disk cache

(split into regular and backup disks). A scheduled controller moves files from regular to backup to allow "cache‑first" strategies while still updating after source changes. Disk cache files are stored as {{domain}}/{{cname}}/{{md5_of_path}} to avoid filename length limits and reduce MD5 collisions. Each binary file is stored together with its content-type in a side‑by‑side .content-type file for fast retrieval.

2. CDN Mechanism

The manager uses a global CDN provided by Wangsu, deployed in North America, delivering millisecond‑level latency worldwide. Default NGINX settings added cache-control: no-cache , overriding the manager’s headers. By adjusting NGINX and enabling Wangsu’s custom cache, the CDN now respects the manager’s cache‑control directives. Special handling is required for resources with timestamp query parameters (e.g., iconfont) to ensure historic timestamps remain effective when needed.

3. Combined Cache Effect

For internal domain requests, the CDN layer is bypassed and the manager’s cache is hit directly. Resources that rely on source‑side acceleration (e.g., luckyorange, googletagmanager) are accessed without caching.

4. Practical Cases

1. Using Google Fonts

Google Fonts are globally popular but can be unstable in certain regions. By routing font requests through the manager, cached copies remain available even if Google services fail. Original CSS:

@font-face {font-family: 'Akronim';font-style: normal;font-weight: 400;src: url(https://fonts.gstatic.com/s/akronim/v12/fdN-9sqWtWZZlHRpygd7lA.ttf) format('truetype');}

Modified CSS to fetch via the manager:

@font-face {font-family: 'Akronim';font-style: normal;font-weight: 400;src: url(https://*.shopexpress.com/gstatic/fonts/s/akronim/v12/fdN-9sqWtWZZlHRpygd7lA.ttf) format('truetype');}

A preceding c‑resources controller rewrites the CSS before the manager serves the font files.

2. Integrating Google Machine Translation

The base library provides a SDK that wraps Google Translate, allowing merchants to enable site‑wide machine translation via the @aquila/client npm package.

import { aquila } from '@aquila/client';
try {
  await aquila.translate.set({ lang });
  console.log(`Target language set to ${lang}, current language ${aquila.translate.get().lang}`);
} catch (e) {
  console.log('Failed to set language', e);
}

The SDK monitors the DOM (white‑list mode) and translates visible text through the manager, abstracting away complex DOM handling and resource scheduling.