CONCEPT Cited by 1 source

Per-entrypoint caching

Definition

Per-entrypoint caching is the design where each named entrypoint within a single deployable compute unit independently opts in or out of caching, with cache evaluation applied to every call between entrypoints — not just to external requests.

When one entrypoint calls another (via ctx.exports in Cloudflare Workers), the cache evaluates the internal call the same way it would evaluate a browser request: a hit returns the cached response without running the callee; a miss runs the callee and stores its response under its own cache key (keyed by entrypoint + path + query string + ctx.props).

Why it matters

Traditional CDN caches sit in front of an origin — a single boundary point. Per-entrypoint caching creates multiple cache boundaries within a single application:

• A gateway entrypoint (auth, routing) runs on every request — cache disabled.
• An expensive backend entrypoint (data fetching, rendering) — cache enabled, keyed per-user.
• A public API entrypoint — cache enabled, shared across all callers.

Each cached entrypoint is an independent unit of memoization with its own key, TTL, and tag namespace for purging.

Composition examples

1. Auth + cached read + write-path invalidation: Gateway always runs → dispatches to cached backend on reads → invalidates via ctx.cache.purge({ tags }) on writes.
2. Caching a Durable Object: Wrap DO reads behind a cached entrypoint; writes go directly to the DO and purge by tag.
3. Normalizing before caching: Outer entrypoint canonicalizes URLs/restores headers → forwards to a cached inner entrypoint that sees only the canonical form.

Seen in

• systems/cloudflare-workers-cache — Workers Cache evaluates cache on every entrypoint call (default export, named WorkerEntrypoint, ctx.exports). Wrangler exports map controls opt-in/out per entrypoint. (Source: sources/2026-07-06-cloudflare-workers-cache)