Resolver Cache with TTL¶
Caching layer — instantiates Registry-Mediated Discovery
Memoizes a resolved locator on the caller's side for a bounded time-to-live, serving repeat lookups locally and, when the source is unreachable, falling back to the last-known-good answer.
A Resolver Cache with TTL is the caller-side mechanism that keeps a resolved answer around so the same lookup need not travel to the registry every time. What makes it this mechanism is that it holds no authority over the data at all — it is a memo of an answer someone else resolved, stamped with a time-to-live after which it must be revalidated. Its two defining behaviors are memoization under a TTL (fast, cheap repeat lookups) and graceful degradation (when the authoritative source is slow or down, serve the last-known-good answer rather than fail). It lives entirely on the consumer side of discovery: it does not decide what is current, it decides how long to trust a currency someone else already established.
Example¶
A mobile app resolves its backend's endpoint at startup and then makes hundreds of calls. Rather than re-resolve every time, its HTTP layer caches the resolved endpoint with a TTL drawn from the response's cache directives. For the TTL's duration, repeat lookups are answered instantly from local memory — no round trip. When the TTL lapses the app revalidates in the background; crucially, it applies a stale-while-revalidate discipline — it keeps serving the cached endpoint while the refresh is in flight, so a slow network never stalls the app, and if the source is briefly unreachable it serves the last-known-good answer under a stale-if-error grace rather than failing outright.[1] The user sees a responsive app on a flaky connection because the cache smooths over both latency and transient source outages — without ever claiming to know the current answer.
How it works¶
On a cache miss the resolver caches the returned locator with an expiry derived from a TTL. Subsequent lookups within the TTL are served locally. At expiry the entry is revalidated — synchronously (block until fresh) or asynchronously (serve stale, refresh in background). The load-bearing behavior is the fallback rule: when revalidation fails because the source is unreachable, the cache does not evict-and-error; it extends trust in the stale entry for a bounded grace window, preferring a possibly-slightly-old answer to no answer at all. This is a deliberate bet that a recently-valid locator is more useful than a hard failure — a bet that pays off precisely in the transient outages that are most common. Negative results may be cached too, briefly, to avoid hammering the source on repeated misses.
Tuning parameters¶
- TTL length — how long a cached answer is trusted before revalidation. Long TTLs cut traffic and latency but widen the window of serving a stale locator.
- Revalidation mode — synchronous versus stale-while-revalidate. Async hides latency at the risk of one extra stale serve; sync guarantees freshness at a latency cost.
- Stale-if-error grace — how far past expiry a stale answer may be served when the source is down. A generous grace maximizes availability and raises the risk of routing to a moved target.
- Negative-cache TTL — how long a "not found" is remembered. Longer protects the source from retry storms and delays discovery of a just-created entry.
- Cache scope — per-caller versus shared. Sharing amplifies hit rate and the blast radius of a poisoned or wrong entry.
When it helps, and when it misleads¶
It is the right mechanism wherever the same locator is looked up far more often than it changes, and where latency and source availability matter — which is almost everywhere at scale. It slashes load on the authoritative source and keeps callers working through its hiccups. Its failure mode is the flip side: a cache serves a stale answer with total confidence, so when a locator genuinely moves, cached callers keep hitting the old address until their TTLs expire — and an overly generous stale-if-error grace can route traffic to a dead or reassigned target long after the truth changed. The classic misuse is inflating TTLs to cut traffic without accounting for how fast the underlying binding really moves. The guarding discipline is to size TTL and grace to the binding's real volatility, and to support prompt invalidation for the rare urgent change.
How it implements the components¶
resolver_cache_policy— its defining contribution: the TTL, revalidation mode, and eviction rules that govern how long a resolved answer is trusted and reused.stale_reference_fallback_rule— the last-known-good / stale-if-error behavior that serves a bounded-stale answer when the source is unreachable rather than failing.
It never establishes liveness or expires a provider's registration — that provider-side freshness_and_liveness_policy and health_signal are Lease or Heartbeat Registration; a cache memoizes a consumer's answer, it does not decide whether the underlying provider is alive.
Related¶
- Instantiates: Registry-Mediated Discovery — the caller-side acceleration-and-degradation layer over any resolver.
- Consumes: Name Resolution Service — caches the answers a resolver produces.
- Sibling mechanisms: Lease or Heartbeat Registration · Name Resolution Service · Service Registry · Registry Query API · Directory Service · Catalog or Broker Directory · Human Referral Directory · Federated Registry Synchronization · Successor Forwarding Record
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Resolver Cache with TTL operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it memoizes a resolved locator on the caller's side for a bounded time-to-live, serving repeat lookups locally and, when the source is unreachable, falling back to the last-known-good answer.
Independent corroboration: The frozen evidence defines Resolver Cache with TTL as 'Memoizes a resolved locator on the caller's side for a bounded time-to-live, serving repeat lookups locally and, when the source is unreachable, falling back to the last-known-good answer', so its operative form is Control, Automation & Runtime.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Caller-side caches with time-to-live and stale fallback are established distributed-systems and naming-service patterns.
Review resolution: Both blind reviewers agree that computer_science is the primary historical origin. Explicit reconciliation of alternate origin disagreement adopts reviewer_a's evidence: Caller-side caches with time-to-live and stale fallback are established distributed-systems and naming-service patterns. The selected record uses alternates=none, origin_mode=single_lineage, and domain_reach=specialized; the other review proposed alternates=engineering_design, origin_mode=single_lineage, and domain_reach=specialized. The selected combination better preserves the mechanism-specific formative lineages and calibrated scope; broader present-day use is not treated as proof of additional historical origin.
Review outcome: Reconciled after independent review; high confidence.
References¶
[1] stale-while-revalidate and stale-if-error (HTTP cache-control extensions, RFC 5861) — directives that let a cache serve a slightly-expired response while it refreshes in the background, or when the origin errors. They are the standard way a caller-side cache trades a bounded risk of staleness for responsiveness and resilience. registry ↩