App Serving Cache
Edge Rendering, Static Content Delivery, Caching & Invalidation
1. Executive Summary
Client web traffic is overwhelmingly read-heavy, requiring fast global delivery of static assets and cached HTML while ensuring that when a business owner publishes an operational update from their phone, the change appears live globally in under 2 seconds without a CI/CD rebuild.
flowchart LR Visitor["Public Visitor Request"] --> Cache["Cloudflare Edge Cache"] Cache -->|"Cache HIT"| Fast:::plain Cache -->|"Cache MISS"| WorkerA["Client Public Worker (Edge SSR)"] WorkerA <-->|"Service Binding"| WorkerB["App-Hosted CMS Worker"] WorkerB -.->|"On Publish"| Purge["Platform Purge Service"] Purge -.->|"Evict Tenant Cache-Tag"| Cache
Fast["Serve Immediately at Edge"] classDef plain fill:none,stroke:none;2. Static Content Delivery & Rendering Boundaries
- Static Assets & Zero-Framework-JS Default:
- Content pages ship with zero client-side framework JavaScript by default; interactive islands are strictly opt-in and deferred below the fold (
client:visible/client:idle). - Web fonts (
.woff2) and static files are served directly frompublic/assets/at the edge (font-display: swap), avoiding third-party font CDNs and external network waterfalls.
- Content pages ship with zero client-side framework JavaScript by default; interactive islands are strictly opt-in and deferred below the fold (
- Edge SSR Shielded by Anycast Caching:
- Non-CMS client sites may build as pure static output (
output: "static"). - CMS-enabled client sites run in Edge SSR mode (
output: "server") shielded by Cloudflare Anycast edge caching (s-maxage,stale-while-revalidate,Cache-Tag).
- Non-CMS client sites may build as pure static output (
- Fail-Safe Graceful Degradation (No Fabricated Fallbacks):
- Public sites never bake fake operational notices or dummy specials into production code as “fallback seeds.”
- Dynamic content slots rely on
stale-while-revalidateandstale-if-errorduring transient upstream hiccups, or gracefully render nothing if an optional banner is absent.
3. Content Invalidation & Read Shielding
- Simple Tenant-Scoped Surrogate Tagging:
- Edge SSR responses carry a tenant-scoped surrogate key (
Cache-Tag: tenant:<client-slug>), avoiding brittle per-component tag bookkeeping.
- Edge SSR responses carry a tenant-scoped surrogate key (
- Sub-2-Second Cache Eviction & Purge Quota Protection:
- When an owner publishes an update in their
app-hostedCMS worker, the worker commits to D1 and invokes theplatform-hostedpurge service (@siteswarm/service-cache-purge, seeMULTI_WORKER_PLATFORM_SERVICES.md) over a Service Binding to evict the tenant’s cache tag globally. - Centralizing purge requests through the platform service keeps Cloudflare Zone Purge tokens out of client workspaces and enforces per-tenant rate limiting and coalescing so a single client cannot exhaust the platform’s shared Cloudflare Purge API quota/bandwidth.
- If a purge API call is throttled or experiences a transient failure, the content save still succeeds and caches refresh naturally within the
stale-while-revalidatewindow.
- When an owner publishes an update in their
- Single-Flight Stampede Defense:
- On an edge cache miss under concurrent load, the public worker coalesces concurrent reads into a single in-flight request backed by a short in-memory micro-cache, protecting backing D1 databases from cache stampedes.