Getting bytes to users worldwide — fast and safely — happens at the edge, before requests ever reach your servers. CDN, DNS, and front-door defense round out the delivery story.
⏱ 30 minPrereq: Units 06, 09You'll be able to: design global delivery and defend the edge
By the end of this unit
Explain what a CDN caches and how it cuts latency and origin load.
Describe how DNS resolves and routes users (geo / latency-based).
Reason about global distribution and where data lives.
Defend the front door: DDoS mitigation, rate limiting, TLS.
CDN — caching at the edge
A CDN (CloudFront, Cloudflare, Akamai) is a global network of edge servers that cache content close to users. A user in Tokyo hits a Tokyo edge node instead of your origin in Virginia — shaving the ~150 ms cross-Pacific round trip and offloading the request from your servers entirely.
Edge serves cache hits locally; only misses go to origin. Most static traffic never touches your servers.
Best for: images, video, JS/CSS, and cacheable API responses.
Cache control: TTLs and Cache-Control headers; invalidate by purging or by versioned URLs (app.v23.js) — same invalidation problem as Unit 06.
Push vs pull: pull CDNs fetch on first miss (simple); push CDNs pre-load content (control over what's where).
DNS — the routing layer
DNS turns api.example.com into an IP. Beyond lookup, it's a routing tool: geo-DNS and latency-based routing return the nearest/healthiest endpoint, and DNS health checks enable failover between regions. It's also your first availability dependency — if DNS is down, nothing resolves (so providers run it as a highly-redundant, anycast service).
Global distribution
Serving users worldwide means deciding where compute and data live. Options range from a single region with a global CDN (simple, but writes are far for distant users) to multi-region active-active (low latency everywhere, but cross-region replication and conflict resolution — back to CAP, Unit 05). Data-residency laws (GDPR) may force certain user data to stay in-region. Name the tradeoff: latency and availability vs replication complexity and consistency.
Defending the front door
Threat / need
Defense
DDoS (volumetric flood)
CDN/edge absorbs & filters traffic; anycast spreads load; scrubbing centers drop bad packets.
Application-layer abuse
WAF (web application firewall) + rate limiting per IP/user/API key at the gateway.
Eavesdropping/tampering
TLS everywhere; terminate at the edge/LB.
Bot/credential attacks
Rate limits, CAPTCHAs, anomaly detection (ties to Unit 16 security).
Edge as a shield "Putting a CDN/edge in front means most DDoS traffic and static load never reach my origin. I'd add a WAF and per-key rate limiting at the gateway, and terminate TLS there." Security at the edge is a clean point to volunteer.
Quick check
Your image-heavy app has great latency in the US but is slow in Asia and your origin bandwidth bill is huge. Best fix?
CDN. The symptoms — far-away users are slow and origin bandwidth is high — are exactly what edge caching solves: images are served locally and most requests never hit your origin, cutting both latency and egress cost.
Quick check
After deploying new JS, some users still load the old version from the CDN. Cleanest fix going forward?
Versioned URLs. A new filename is a new cache key, so clients fetch the new asset immediately while old ones can stay cached harmlessly. TTL=0 defeats the point of the CDN; manual purges work but are error-prone for every deploy.
Practice before you move on
Add the delivery layer to the photo app: which assets go through the CDN, how you invalidate after an edit, how DNS routes a user in Europe, and two front-door defenses you'd call out. One paragraph, interview-voice.