Components, Workflow, and API
In one line: most people can name "edge servers" and stop. The routing system, distribution system, scrubbers, and management plane are where the interesting design decisions live — and they are what an interviewer probes when they ask how the thing actually works.
The components
| Component | Responsibility |
|---|---|
| Clients | End user devices — browsers, smartphones — requesting content |
| Routing system | Directs clients to the optimal CDN facility, using content placement, request volume, server load, and URI namespaces to find the nearest available server |
| Scrubber servers | Separate legitimate from malicious traffic (e.g. DDoS); typically engaged when an attack is detected, cleaning traffic before routing it on |
| Proxy servers | Edge servers that serve content; hot data in RAM, cold data on SSD or disk; also report accounting information to the management system |
| Distribution system | Distributes content from origin to edge proxies using intelligent broadcast mechanisms |
| Origin servers | The source of truth; serve content unavailable in the CDN and store mapping metadata |
| Management system | Monitors latency, downtime, packet loss, and server load; tracks resource usage for billing |
Note the RAM/disk split inside a proxy
Proxy servers store hot data in RAM and cold data on SSDs or hard drives. That is a two-tier cache inside each edge node, and it is what lets a single proxy serve both a viral video (from memory, at wire speed) and an obscure one (from disk, still far faster than crossing an ocean).
It also connects directly to the long-tail problem in Lesson 6: the tail lives on disk, and disk at the edge still beats RAM at the origin.
The workflow
Spelled out:
- The content provider delegates a URI namespace or domain to the CDN request-routing system so it can resolve incoming requests.
- Origin servers publish content to the distribution system.
- The distribution system distributes content to edge proxies, and may send feedback to the routing system about content availability and location.
- A client queries the routing system for a suitable server.
- The routing system returns the address of the optimal edge server, based on proximity, latency, load, availability, and cache state.
- If security scrubbing is enabled, the request first passes through scrubber servers filtering malicious traffic.
- After validation, scrubbers forward the safe request to the selected edge proxy.
- The edge proxy serves the content. If it is not cached, the proxy retrieves it from a parent cache, the distribution system, or the origin.
API design
Five internal APIs. "Content" here means any web object — files, videos, audio. Privacy parameters such as encryption and access control are omitted for brevity.
Retrieve — proxy server to origin server
Proxy servers use GET to fetch content from origin via /retrieveContent:
retrieveContent(proxyserver_id, content_type, content_version, description)
| Parameter | Description |
|---|---|
proxyserver_id | Unique ID of the requesting proxy server |
content_type | Category (audio, video, document, script), the client types it's requested for, and requested quality |
content_version | Version number. For this API it holds the version currently at the proxy, or NULL if none |
description | Content detail — e.g. a video's extension and resolution |
Returns a JSON object with the text, content type, and links to embedded media.
Deliver — origin server to proxy servers
Origin servers push new or updated content through the distribution system:
deliverContent(origin_id, server_list, content_type, content_version, description)
| Parameter | Description |
|---|---|
origin_id | Uniquely identifies the origin server |
server_list | The servers the distribution system will push content to |
content_version | The updated version at origin; the receiving proxy discards its previous version |
Request — clients to proxy servers
requestContent(user_id, content_type, description)
| Parameter | Description |
|---|---|
user_id | Unique ID of the requesting user |
The proxy returns the requested content to the client.
Search — proxy server to peer proxy servers
Proxies probe peers in the same PoP before falling back to origin, either by broadcasting a query or checking a shared data store:
searchContent(proxyserver_id, content_type, description)
This is a meaningful optimization: a peer in the same building is far cheaper to reach than the origin across a continent.
Update — proxy server to peer proxy servers
updateContent(proxyserver_id, content_type, description)
| Parameter | Description |
|---|---|
proxyserver_id | Identifies the proxy server in the PoP whose content is being updated |
Often triggered by serverless scripts performing tasks such as image resizing or format conversion.
On the Delete API
Delete is not detailed here. Cache eviction policies typically remove stale entries automatically, but explicit deletion may be required to maintain consistency across edge nodes — the purge case, when content must disappear immediately rather than at TTL expiry. Consistency mechanisms are covered in Lesson 8.
Key takeaway
The routing system decides where a request goes; the distribution system decides where content lives; the feedback loop between them is what makes routing actually good rather than merely geographic.
Interview signal by level
| Level | What a strong answer sounds like |
|---|---|
| L4 | Draws clients, edge servers, and origin. |
| L5 | Adds the control path: "a routing system picks the edge, and a distribution system pushes content out from origin." |
| Staff+ | Closes the loop: "the distribution system feeds cache state back to routing, so we route on content availability and not just proximity — otherwise we send users to a near edge that has to fetch from origin anyway." |
Next: the two ways content gets to the edge.