Evaluating the Design
Why this matters: stating requirements and then never returning to them is the most common structural weakness in a design interview. This lesson closes the loop — and the habit transfers to every problem.
Key takeaway
A design is not finished when the diagram is drawn. It is finished when you can walk each stated requirement and point to the specific mechanism that satisfies it.
Performance
The CDN achieves high performance by minimizing latency through several decisions:
| Decision | Effect |
|---|---|
| Serve frequently accessed content from RAM | Hot content answered at memory speed |
| Geographically distributed proxies | Content sits closer to users, cutting propagation delay |
| Deploy within ISPs or IXPs | Handles high traffic efficiently, often one hop from users |
| Request routing to the nearest proxy | Users reach the best edge by network distance and load |
| Long-tail content on SSD or HDD | Serving from local storage is far faster than fetching from origin |
| Layered proxy architecture | Edges request missing content from parents — efficient when specific ISP regions generate high traffic |
Note the RAM/disk split appearing again: the head is served from memory, the long tail from local disk. Even a disk hit at the edge beats a memory hit at an origin across an ocean.
Availability
The distributed nature of a CDN handles massive traffic loads:
- Cached content acts as a backup if origin servers fail — the edges keep serving even with the source down.
- Redundancy ensures that if a proxy goes down, traffic is rerouted to operational servers.
- Load balancers distribute requests to nearby active proxies to prevent overloading.
Scalability
Three ways:
- Offloading traffic to edge servers reduces bandwidth requirements on the origin.
- Horizontal scaling by adding more edge proxy servers.
- A layered proxy architecture overcomes the storage and scaling limits of individual servers.
Reliability and security
- Redundancy and load distribution reduce single points of failure.
- Scrubbing infrastructure mitigates DDoS attacks.
- Heartbeat-based health checks detect and isolate unhealthy nodes.
- Sensitive real-time applications may use private CDNs to improve traffic isolation and strengthen access control.
The requirements, closed out
| Requirement | Satisfied by |
|---|---|
| Performance | Edge proximity + RAM/disk tiering + nearest-proxy routing + parent hierarchy |
| Availability | Geographic distribution + cached content surviving origin failure + rerouting + load balancing |
| Scalability | Origin offload + horizontal edge scaling + layered architecture |
| Reliability and security | Redundancy + scrubbers for DDoS + heartbeat health checks + private CDN isolation where needed |
Conclusion
Since the 1990s, CDNs have played a central role in delivering content with high availability and low latency. They continue to support the scalability and performance requirements of modern large-scale systems.
Key takeaway
Every requirement should map to a mechanism, and every mechanism should trace back to a requirement. Anything in the design that maps to neither is complexity you have not justified.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | Finishes when the diagram is drawn. |
| L5 | Summarizes the design and its main benefits. |
| Staff+ | Closes the loop deliberately: "let me check this against what we said we needed — performance comes from edge proximity and tiering, availability from cached content surviving an origin outage, scalability from origin offload. Security is the one I'd want to spend more time on if we had it." |
Next: the full design under interview conditions.