Components, Workflow, and API

Why this matters: 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.

Key takeaway

A CDN has seven components. The ones that matter most in a design discussion are the routing system (which edge should serve this user?) and the distribution system (how does content reach the edges?) — everything else is comparatively mechanical.

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

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.