Edge and Origin

The Roles

 ORIGIN: source of truth. your infrastructure. slow-ish, expensive,
         capacity-limited — but authoritative.

 EDGE:   proxy + cache near users. fast, disposable, massive
         aggregate capacity. serves copies; never the truth.

 contract between them: cache headers + purge APIs.
 everything else (routing, shielding, compute) is implementation.

The Request Lifecycle

 user → nearest edge:
   HIT    edge serves from disk/memory           (~10ms total)
   MISS   edge must fetch:

     edge ──► shield (mid-tier cache):
                hit  → served, edge caches it now
                miss → origin fetch (THE only origin request)

 miss fan-out math:
   no shield:  300 edges × first-request = up to 300 origin hits/object
   with shield: ~1-3 origin hits/object (shield dedupes regions)

 configure ONE or TWO shield locations — this setting alone
 often determines whether origin survives launch day.

Request Coalescing at Every Tier

 50 users in Manila request the same cold video segment
 within the same second:

 without coalescing: 50 identical origin fetches
 with coalescing:    first request fetches; other 49 WAIT,
                     then get served from the fill

 CDNs do this internally (request collapsing).
 your origin should too — same pattern, one tier down.

What Origins Owe Edges

Obligation	Why
Correct Cache-Control/Surrogate headers	Edges obey YOUR declarations
Stable URLs for stable content	Key fragmentation kills hit rates
Fast error semantics	5xx storms get amplified by retries
Health endpoints	Edge failover decisions
Purge API usage discipline	Trust-but-audit bad content removal

 header design is ORIGIN-SIDE work:
   Surrogate-Control: max-age=86400      ← edge obeys this
   Cache-Control: max-age=60             ← browser gets this
 two audiences, two headers — a classic production subtlety.

Origin Protection Posture

 origin should be UNREACHABLE except via CDN:
 - firewall/allowlist CDN IP ranges only
 - authenticated fetches where supported
 - origin receives: filtered traffic, real client IPs restored
   (X-Forwarded-For chain), consistent TLS termination

 benefits: DDoS surface shrinks to CDN capacity (massive),
 direct-to-origin attacks bypass nothing.

Failure Semantics

 origin down ≠ site down (if configured):

 - stale-if-error: edges serve expired copies during origin outage
 - stale-while-revalidate: background revalidation hides blips
 - negative TTLs on origin errors: don't hammer a dying origin

 design goal: origin incidents degrade FRESHNESS,
 not availability. users keep using slightly-stale content.

Interview Framing

“Draw the delivery path” questions expect: user→edge→(shield)→origin, coalescing mentioned at each boundary, two-header subtlety, origin allowlisting behind CDN, and stale-serving failure modes. The phrase “origin sees misses, not traffic” compresses the whole architecture — use it.