Synopsis
This chapter explains how to design and operate origin infrastructure that can serve more than one CDN at the same time. It covers topology choices, origin shielding, authentication, cache key consistency, deployment and consistency models, failover behavior, and operational practices. The goal is to keep content correctness and performance stable while multiple CDNs fetch from the same source.
Role of the origin in multi-CDN
The origin is the source of truth for content and APIs. In a multi-CDN setup more than one provider will fetch from it. The design must handle higher fan in, different retry behaviors, and different cache semantics without breaking correctness. It should also keep the number of variables low so that problems are diagnosable during incidents.
Topology choices
A single origin with a shielding layer is simple and effective for static or read heavy traffic. CDNs fetch from a small set of shield nodes that sit in front of storage or application servers. This reduces duplicate fetches and protects the core from bursts. Multi region origins reduce latency and allow regional isolation when laws or contracts require it. Active active works for static assets and idempotent APIs when data replication is fast and consistent. Active standby can protect write heavy systems when consistency rules are strict. Selection should favor the simplest model that meets latency and availability goals, with a documented fallback path if a region or provider is degraded.
Addressing and host identity
The method by which CDNs reach the origin must be clear. A shared origin hostname keeps configuration uniform and simplifies certificate and token rotation. Separate per provider hostnames allow fine grained firewall control and more detailed logs but increase configuration drift risk. The Host header and SNI must match the certificate served by the origin. When a shield or proxy fronts the origin, the upstream Host header should remain stable so cache keys and virtual hosts behave predictably. Internal names should not be exposed to clients. Origin DNS is part of production; low TTLs are used only when fast failover is required and resolver behavior has been tested.
Origin authentication and authorization
The origin must be protected from the open internet. At minimum use IP allowlists that cover the known egress ranges of each CDN and private probes. Prefer private connectivity or peering when available. For request level authentication three patterns are common. Signed URLs or cookies bind the request to key material and can be verified at the edge and at the origin. Header tokens generated by a control plane can authorize fetches from CDNs without exposing client tokens to the origin. Mutual TLS between CDN and origin authenticates the caller at the transport layer. Token and certificate rotation should be automated and testable. Time skew and clock drift break short lived tokens; verification failures by source network must be monitored and alerted.
Shielding and mid tiers
Origin shielding places a stable cache or proxy between CDNs and the core. It reduces duplicate miss traffic and smooths bursty demand. When shielding is used, a clear boundary for cache and compression must be set. Either the shield owns compression and upstreams in a consistent format, or the origin owns compression and the shield passes it through. Mixing responsibilities leads to inconsistent objects and lower hit ratios. Shield hit rate should be measured separately from edge hit rate so the effect of policy changes on the core is visible.
Cache keys and content identity
Multi-CDN requires consistent object identity. A canonical cache key should use scheme, host, normalized path, and a well defined set of query parameters. Unbounded headers in the key should be avoided. HTTP Vary should be used only for headers that are truly needed. Accept-Encoding and Accept are common but can explode key space if not controlled. Immutable versioned asset URLs are preferred for static content so purges are rare and predictable. For dynamic content, ETag and Last-Modified must be accurate so conditional requests work across providers. If a CDN performs image or video transforms at the edge, deterministic transform URLs should be published so both providers can cache identical results.
Consistency and deployment
For static assets a store-once, replicate, then publish approach reduces partial visibility. For dynamic content, correctness rules must match user needs. Strong consistency is rarely required for images and scripts, but it is common for API responses that reflect user state. When purge is part of the model, purge commands must be idempotent and each provider must expose a working API with sane rate limits. Soft purge with revalidation reduces origin load during rollouts.
Failover and retry behavior
CDNs differ in retry behavior. The origin should be protected with sensible timeouts and exponential backoff. Idempotency should be explicit when methods change state. Aggressive retries can amplify traffic during partial outages. Upstream requests per provider should be monitored and concurrency capped where possible. Stale-if-error and stale-while-revalidate keep users served during short incidents without overloading the core. Error codes should be mapped consistently so dashboards carry the same meaning across providers.
Range requests and large objects
Video and software distribution rely on range requests. The origin and any shield must serve ranges from cached objects without re fetching the entire file. Byte range coalescing should be supported where possible. Validation headers must work with ranges so partial responses do not bypass cache correctness. Partial content should be tested with cold and warm caches for each CDN.
Compression and content negotiation
Compression rules must be identical across providers. If compression occurs at origin, both CDNs must store separate encodings and Vary on Accept-Encoding must be set. If compression occurs at the edge, settings should be standardized and origin to shield transfers should use a single canonical encoding. Automatic content negotiation features that add or remove headers can fork cache keys and harm hit rate and should be handled carefully.
Logging and traceability
Each request should carry a stable id from edge to origin so logs can be joined across systems. Access logs should record the selected CDN, shield, and origin region. Retention must be sufficient for investigations without storing sensitive data longer than necessary. When a routing change affects cache hit rate or origin errors, traceability across the chain is required.
Capacity planning
Higher miss traffic is expected when a second CDN is added. Warmup effects, new regions, and policy experiments increase origin load at first. Shields and origin pools must be sized for the worst credible burst. Surge paths should be exercised in controlled tests. Budgets for egress, storage, and request rate should be tracked alongside SLOs so tradeoffs are explicit.
Operations
Certificate renewal, token rotation, and drift checks should be automated. Origin health checks must reflect real readiness, not only TCP reachability. Failover should be tested in production with controlled scope. Inbound firewall rules, origin hostnames, and certificate issuers should be documented so on call engineers can act without guesswork. Configuration reviews with providers should occur regularly to close gaps.
Related chapters
For a comparison of steering layers see /multicdn/architecture-patterns/. For policy design read /multicdn/traffic-steering/. For measurement and inputs see /multicdn/signals-telemetry/.
Further reading
RFC 9110 for HTTP semantics. RFC 9111 for HTTP caching. RFC 8446 for TLS 1.3. RFC 8555 for ACME automation.