Network engineering
CDN Network Design: Model Cache Hits, Origin Traffic and Failure Capacity
Size a CDN edge network from delivered bytes, cache behavior, origin recovery and the complete server-to-network path.
A CDN edge node serves traffic from a combination of cached objects and origin fetches. Its network must support both normal delivery and the less favorable states that occur after deployment, invalidation or failure. Sizing only for a high steady-state cache-hit ratio can leave the origin path or servers undersized when the cache is cold.
Distinguish request counts from bytes
A request hit ratio describes how many requests are served from cache. A byte hit ratio describes how much delivered data comes from cache. They can differ substantially when object sizes vary. Use the metric appropriate to the capacity calculation.
For an illustrative simplified model, assume 100 Gb/s of client delivery and an 85% byte hit ratio. Ignoring protocol overhead, revalidation and other traffic, approximately 15 Gb/s must be fetched from origin. If the byte hit ratio falls to 40%, the corresponding estimate becomes 60 Gb/s. These are planning calculations, not predictions of a particular CDN product.
Model the exceptional states
| State | Capacity or behavior to examine |
|---|---|
| Warm cache | Client delivery, storage reads and steady origin traffic |
| Cold cache | Origin fetch capacity and concurrent object creation |
| Large invalidation | Sudden misses and protection of upstream services |
| Node loss | Traffic shifted to remaining nodes and cache locality changes |
| Origin impairment | Permitted freshness behavior and user-visible errors |
HTTP caching rules govern whether stored responses can be reused. Freshness, validation and request/response directives must be respected; a network capacity target does not authorize serving private or otherwise unsuitable content from a shared cache. R33
Size the server and network together
Map client-facing and origin-facing traffic through NICs, switch ports, uplinks and any security or load-balancing systems. Include the actual server storage and processing path. A 100G interface does not establish that a node can sustain 100 Gb/s of useful object delivery under the chosen object mix and connection behavior.
Measure concurrency, object-size distribution and delivery characteristics representative of the service. Keep encrypted-connection processing and cache-management work visible where they affect the system.
Define resilience as remaining service capacity
After one node or uplink fails, calculate the traffic assigned to the survivors. Consider whether replacement nodes start with a warm or cold cache. An additional server with an empty cache may increase origin demand before it improves delivery capacity.
Use rate controls and rollout procedures appropriate to the application so that a recovery event does not overwhelm the upstream service. These controls belong in the operational design, not only in a switch purchase specification.
Validate with a service workload
Test warm and cold conditions separately and retain the object corpus, concurrency, cache policy and network topology with the results. Isolate disruptive throughput tests from production; laboratory benchmark guidance should not be applied uncritically to a live network. R46R47
The final design should connect cache assumptions to node counts, origin capacity, uplink budgets and a recovery procedure. A useful enquiry includes delivery demand, byte-hit behavior, object mix, origin constraints and the failure state that must remain serviceable.
Engineering illustrations
These figures illustrate the design concepts discussed here. They are not measured results, certified configurations or a supplied-equipment list.
