Content Delivery and Edge Networking Questions

Requirements:

• Support targeted per-object invalidation and bulk/global invalidation.
• Avoid overloading CDN control plane (rate limits, high cost).
• Provide safe, performant purge APIs for operators with auditability and fallback.

Design summary:

1. Origin-side metadata + surrogate-keys

• When responding, origin sets Cache-Control + Surrogate-Key header grouping related objects (e.g., "article:123,author:45,assets:mobile").
• CDN indexes surrogate-keys so you can invalidate by key instead of many individual URLs.

2. Versioned URLs for cheap invalidation

• Use content-based or semantic versioning in URLs (e.g., /assets/123.v{hash}.js or ?v=20251201). Deploys that change content generate new URLs so old objects naturally expire without purge.

3. Soft-purge vs Hard-purge

• Soft-purge: mark content invalid in an origin-maintained keystore (e.g., Redis) and set CDN to revalidate via conditional requests (If-None-Match). Fast, avoids control-plane, but requires origin to honor validation headers. Good for per-object and bulk with grace TTL.
• Hard-purge: call CDN invalidate APIs for immediate removal (Use sparingly). Rate-limit and batch operations.

4. CDN control-plane protection

• Throttle purge requests using a purge service that:
  • Batches per-key invalidations into single surrogate-key purge calls.
  • Debounces rapid repeated purges for same key.
  • Converts bulk tag invalidations into incremental staged purges to avoid spikes.
  • Falls back to versioned-URL technique when control-plane rate limits hit (issue new version token and update references).

5. Operator-safe purge APIs

• Provide two operator APIs:
  • Fast (dry-run + staged) soft-purge: accepts surrogate-key(s) or query, marks invalidation in origin datastore, returns async job id, non-destructive by default.
  • Immediate hard-purge: requires justification, rate-limited, RBAC + approval for global purges, returns progress and estimated impact.
• Always support dry-run, preview (list affected URLs via index), and audit logs + immutable job records.
• Expose metrics and alerts: purge latency, control-plane errors, queue length, failed staged batches.

6. Consistency & fallbacks

• Set short Cache-Control on dynamic content; long for versioned assets.
• If urgent security issue and CDN rejects purge, rotate URL versions and push immediate client-side refresh (cache-busting headers, set Set-Cookie with short TTL).

Trade-offs:

• Surrogate-keys + soft-purge reduces control-plane use but relies on origin revalidation and extra origin load.
• Versioned URLs increase storage/cache footprint but avoid purges.
• Hard-purge is costly and should be emergency-only.

This strategy balances safety, performance and CDN control-plane limits by preferring origin-driven invalidation (surrogate-keys + soft-purge + versioning), using a purge service to protect the CDN API, and giving operators controlled tools with auditing and RBAC.

A CDN is a globally distributed cache and request-routing layer that serves static and cacheable dynamic content from edge locations close to users to reduce latency, lower origin load, and improve availability. It differs from an in-application (local) cache: a CDN is a network-level, multi-tenant, geo-distributed cache optimized for HTTP delivery and routing; an in-app cache (e.g., Redis, memcached, or local in-process cache) is a single-tenant data-store used to reduce backend latency or computation and often stores finer-grained application state, not HTTP headers/objects.

Edge caching & origin fetches:

• Edge caches store objects until TTL/validation expires. On a cache miss the edge issues an origin fetch (conditional or full), then serves and caches per headers.
• Use conditional requests (If-Modified-Since/ETag) to reduce bandwidth.

Cache-Control headers:

• Control behavior: max-age, s-maxage (CDN-specific), public/private, no-cache, must-revalidate, stale-while-revalidate.
• s-maxage overrides max-age for shared caches (CDNs). Set appropriate headers for sensitive data (private) vs static assets.

When to use CDN vs in-app cache:

• CDN for global latency reduction, bandwidth offload, DDoS protection, TLS termination at edge, and caching HTTP responses.
• In-app cache for business logic, sessions, computed results, or non-HTTP data needing strong consistency or fine-grained invalidation.

Operational concerns:

• Cache invalidation: prefer TTLs + cache-busting (versioned URLs). Use CDN purge APIs for immediate invalidation; purges can be eventual and costly.
• TLS at edge: terminate TLS at CDN edge for performance—ensure origin authentication (mTLS, origin pull TLS) and certificate management; watch for TLS policy compatibility and SNI.
• Debugging cache misses: inspect response headers (Age, X-Cache, Via), use edge logs, simulate requests from edge locations, check Cache-Control and Set-Cookie (cookies often bypass caches), and verify request headers (Authorization, cookies, Vary). Monitor origin fetch rates and alert on elevated origin traffic.
• Metrics & SLOs: track cache hit ratio, origin bandwidth, tail latency, purge frequency, and cost.

Trade-offs: CDNs simplify delivery and scale but add complexity (purges, stale content windows, need for origin auth). Combine both: CDN for distribution + in-app caches for backend efficiency.

A CDN (Content Delivery Network) is a distributed set of edge servers that cache and serve content close to users to reduce latency, lower origin load, and increase availability. It routes requests to the nearest/least-loaded edge and falls back to origin when content is missing or invalidated.

Edge caching vs origin caching:

• Edge caching: cache at CDN POPs for low-latency, high-read traffic (static assets, public API responses). Use when data is mostly identical across users and can tolerate TTL-based staleness.
• Origin caching (or short TTLs + CDN pass-through): keep authoritative copies at origin. Use for highly dynamic, secure, or frequently changing data.

For a product with static assets and personalized HTML:

• Cacheable at CDN: static assets (JS/CSS/images), public CDN-friendly HTML fragments (e.g., templates without user-specific data), API responses that are identical per key.
• Must be served from origin (or per-user backend): truly personalized content (full HTML containing user secrets), authentication-protected endpoints, rapidly changing user state.

Techniques to safely cache personalized content:

• Cache key segmentation: include user-id, country, device, or AB-test flags in cache keys only when safe.
• Vary and Cache-Control: use Vary headers (Accept-Encoding, Cookie) and set appropriate Cache-Control (private, public, s-maxage) — s-maxage for CDN-only TTL.
• Edge-side includes (ESI) / fragment caching: serve common shell from CDN, fetch small personalized fragments from origin or signed cookies.
• Tokenized short-lived caches: use signed cookies or JWTs for per-user edge cache keys with short TTL.
• Cache purging and surrogate keys: allow fast invalidation of groups of objects.
• Stale-while-revalidate / stale-if-error: improve availability while refreshing in background.
• Strip/normalize cookies: remove irrelevant cookies from cache key to increase hit ratio.

As an SRE, balance cache hit-rate vs correctness, monitor cache TTLs/hits/misses, and automate purge/rollbacks to meet SLOs without exposing stale or private data.