Skip to content

Local Inventory or Edge Cache

Pre-positioned artifact — instantiates Endpoint Fan-Out Fulfillment

A forward-placed buffer of the frequently-needed goods, data, or capability held close to endpoints, so the common request is served locally — fast, and still served when the trunk is slow or down.

Local Inventory or Edge Cache is a buffer of the most-needed things, placed near endpoints ahead of demand so the common request never has to travel back to the trunk. Its defining move is proactive placement by predicted demand: rather than fetching each request from the centre, it forecasts what a locale will want, pre-positions that subset at the edge, serves it locally on a hit, and falls back to the trunk only on a miss. That single design choice buys two things at once — latency (the frequent case is close) and resilience (the buffer keeps serving through a trunk disruption). What it is not is a place where handoff happens or capacity that travels; it is stock that sits, waiting, where it will most often be needed.

Example

A streaming service serves millions of plays from a handful of origin datacentres — the trunk. Streaming every play from origin would be slow to start and would collapse the moment an origin link hiccuped. So it runs a content delivery network: the titles a region is actually watching this week are copied onto edge cache servers sitting inside local ISPs, close to viewers. A play hits the nearby cache, starts in a fraction of the time, and — because roughly the popular ≈5% of the catalogue accounts for most views — a small cache captures most demand. When an origin path degrades, the cached titles keep playing. As what's popular shifts, the cache refreshes and evicts stale titles.

The artifact here is the pre-positioned copy: forecast-chosen, edge-placed stock that serves the common case locally and absorbs the shock when the centre wobbles.

How it works

  • Forecast the local working set — predict which goods, data, or capability each locale will most demand, because you cannot pre-position everything.
  • Pre-position that subset at or near the endpoints, ahead of the requests.
  • Serve on hit, fall back on miss — the local buffer handles the frequent case; the trunk backstops the rest.
  • Refresh and evict as demand shifts, so the buffer keeps tracking what is actually wanted.

The distinguishing logic is anticipation: the buffer commits stock before the request arrives, betting on a forecast, and earns its keep only to the extent that forecast is skewed and stable.

Tuning parameters

  • Cache size / coverage — how much of the demand curve to hold locally. Larger captures more requests but costs holding and space; too small and the hit rate collapses.
  • Placement depth — how close to the endpoint the buffer sits. Deeper cuts latency further but multiplies the number of copies to keep fresh.
  • Refresh / eviction policy — how fast the buffer tracks changing demand, trading freshness against churn.
  • Staleness tolerance — how out-of-date a local copy may be before it must be re-synced, balancing speed against serving something outdated.
  • Hit-rate target — the fraction of requests the buffer aims to serve locally, which sets everything above.

When it helps, and when it misleads

Its strength is skewed demand: when a small popular subset dominates, a modest buffer delivers most requests fast and shields endpoints from trunk outages at low cost.

Its failure modes are holding cost and staleness. A buffer stocked with the wrong things is pure expense, and a stale local copy quietly serves outdated goods or data as if fresh — a subtle, trust-eroding failure. The classic misuse is caching everything "to be safe," which defeats the economics that justified the buffer, or never evicting, so the buffer ossifies around last season's demand. The discipline that keeps it honest is to size to the measured working set, watch the hit rate as the real scorecard,[1] and evict on demand decay rather than on sentiment.

How it implements the components

  • demand_forecast — the buffer's contents are chosen by a forecast of local demand; pre-positioning is impossible without it.
  • resilience_and_contingency_path — the local buffer is a standing fallback: when the trunk is slow or unreachable, cached stock keeps the endpoint served.

It does not provide the physical node where flow is broken down and handed over — that is the Micro-Hub or Pickup-Point Network — nor does it travel to reach sparse endpoints, which is the Mobile Service Unit.

Notes

The cache and the hub are easy to conflate because they often share a building — stock in a locker room, spares in a depot — but they answer different questions. The cache is what is stored ahead of need; the hub is where the handoff happens. A site can be one, the other, or both, and treating them as separate design choices keeps the "what to pre-position" decision from being quietly dictated by "where we happen to have a node."

References

[1] The cache hit ratio — the share of requests served from the local buffer rather than fetched from origin — is the standard measure of whether a cache is earning its place. A buffer with a low hit rate is holding the wrong working set, however full it looks. ↩