Caching Architecture & Delivery

ArylHive’s performance heavily relies on aggressive caching at the CDN Tier-1 level. This document maps out exactly how static assets, extracted ZIP contents, and API responses are cached to achieve sub-10ms TTFB (Time To First Byte).

1. Native Cloudflare Cache API

Unlike basic setups that simply rely on Page Rules, the Edge Controller manually interacts with the caches.default JS API. This allows deterministic, programmatic control over precisely what gets cached, what gets purged, and what is served dynamically.

sequenceDiagram participant User participant Worker as CF Worker Edge participant Cache as CF Tier-1 RAM Cache participant Origin as B2 / Storage User->>Worker: Request Asset (/style.css) Worker->>Cache: caches.match(request) alt Cache HIT Cache-->>Worker: Return Response (1ms) Worker-->>User: 200 OK (Served from Edge) else Cache MISS Worker->>Origin: Fetch or Extract Asset Origin-->>Worker: Stream payload %% Non-blocking cache put Worker-)Cache: ctx.waitUntil(caches.put(request, clone)) Worker-->>User: 200 OK (Served & Cached Async) end

2. ZIP Extraction Caching (The Fast Path)

For GitHub deployments, entire applications are stored natively as .zip files on Backblaze B2/R2. Extracting these per-request would be CPU intensive.

The Cold Path: The Worker identifies a cache miss. It makes a precise HTTP Byte Range lookup to B2 to pull the Zipped blocks, unzips using fflate, and serves the file. Crucially, before returning the file, it executes an asynchronous caches.default.put() with a 1-Year Cache TTL (max-age=31536000).
The Hot Path: Every subsequent visitor globally fetches the extracted, uncompressed payload directly from Cloudflare's massive RAM cache. 99.9% of traffic to popular deployments bypasses the unzipping logic completely.

3. Cache Invalidation Strategy

How do we handle cache purging without global purge delays? We don't. ArylHive utilizes an Immutable Cache Architecture.

When a user triggers a new build or updates a website, the deployment hash natively changes (e.g., deploy_A1B2C.zip → deploy_X9Y8Z.zip). Because the Cache keys are generated deterministically based on the deployment hash internally, a new deployment generates completely distinct cache keys instantly worldwide.

graph TD subgraph Version 1 (deploy_ABC.zip) URL1[https://mydomain.com/style.css] --> Internal1(Cache Key: deploy_ABC/style.css) Internal1 --> Hit1[Cached Asset V1] end subgraph Version 2 (deploy_XYZ.zip) URL2[https://mydomain.com/style.css] --> Internal2(Cache Key: deploy_XYZ/style.css) Internal2 --> Miss2[Cache Miss -> Fresh Fetch] end style URL2 stroke:#3b82f6 style Internal2 stroke:#3b82f6

4. API Caching Principles

The Dashboard APIs intentionally bypass caching to guarantee strong transactional consistency (e.g., triggering deployments, modifying environment variables, accessing logs). These endpoints explicitly append Cache-Control: no-store headers and route requests securely against the LibSQL cluster.

Next: Learn about Custom Domains & SSL →