CDN Upload and Download Flow: How Facebook Serves Videos Globally

Upload Process: Storing Content 📤

Scenario: Abdul uploads a video to Facebook.

![image](/api/blog-assets/hld/.gitbook/assets/image%20(9).png)

Step 1: Upload to Facebook Servers

Abdul's video connects to Facebook's backend. The video file is not stored in SQL or MongoDB. Instead, it goes to specialized file storage:

Amazon S3 (Simple Storage Service)
HDFS (Hadoop Distributed File System)
Similar to Google Drive, but optimized for large-scale video/image storage

Step 2: Metadata Storage

Facebook stores metadata in a traditional database (SQL or MongoDB):

Uploader: Abdul
Upload timestamp: 2026-02-01 14:30:00
File name: birthday_party.mp4
File size: 250 MB
Original file URL: s3.aws.com/videos/12345.mp4

Step 3: CDN Registration

Facebook sends a request to the CDN provider (e.g., Akamai):

Facebook → Akamai:
"I have a video at s3.aws.com/videos/12345.mp4. Please cache it."

Akamai → Facebook:
"Cached. Use this URL for delivery: cdn.akamai.com/a32b_cached.mp4"

Facebook stores the CDN URL (not the database URL) in its metadata table.

Note: In reality, Facebook operates Facebook CDN (fbcdn.net) rather than using third-party providers like Akamai.

Download Process: Serving Content to Users 📥

Scenario: Upintha wants to watch Abdul's video.

Step 1: Request to Facebook Backend

Upintha's browser sends: GET /watch-video/12345

Step 2: Facebook Returns HTML with CDN URL

Facebook's server returns an HTML file containing:

<video src="cdn.akamai.com/a32b_cached.mp4"></video>

Critical point: Facebook does not return the database URL (s3.aws.com/videos/12345.mp4). It returns the CDN URL.

Step 3: Browser Requests Video from CDN

Upintha's browser parses the HTML and makes a request to cdn.akamai.com/a32b_cached.mp4.

Step 4: CDN Serves from Nearest Edge Node

The CDN routes Upintha to the geographically closest edge server.

The edge server checks: "Do I have this file cached locally?"

If cached locally: Return the file immediately (low latency, high bandwidth)

If not cached locally:

Fetch from original source (s3.aws.com/videos/12345.mp4)
Cache it locally
Return to Upintha

URL Flow Diagram 🔀

Abdul uploads video
    ↓
Database stores: s3.aws.com/videos/12345.mp4
    ↓
Facebook registers with CDN
    ↓
CDN returns: cdn.akamai.com/a32b_cached.mp4
    ↓
Facebook stores CDN URL in metadata
    ↓
Upintha requests video
    ↓
Facebook returns HTML with CDN URL (NOT database URL)
    ↓
Browser requests from CDN edge node
    ↓
Edge node serves cached file

CDN Internal Mapping 🗺️

Inside the CDN, a mapping table stores:

Original URL          → CDN URL
s3.aws.com/videos/12345.mp4 → cdn.akamai.com/a32b_cached.mp4

When an edge server receives a request for cdn.akamai.com/a32b_cached.mp4:

Check local cache: "Do I have this file?"
Cache hit: Serve immediately
Cache miss: Look up mapping → Fetch from s3.aws.com/videos/12345.mp4 → Cache locally → Serve to user

Cache Hit vs. Cache Miss 📊

First Request (Upintha) - Cache Miss

Upintha requests video
    ↓
Edge server checks cache → MISS
    ↓
Edge server fetches from s3.aws.com/videos/12345.mp4
    ↓
Edge server caches file locally
    ↓
Edge server serves to Upintha

Subsequent Request (Pankaj) - Cache Hit

If Pankaj (Upintha's neighbor) requests the same video, he routes to the same edge server:

Pankaj requests video
    ↓
Edge server checks cache → HIT
    ↓
Edge server serves cached file immediately (no database fetch)

Why This Architecture Works 🎯

Users always contact Facebook servers first to get the CDN URL. They cannot directly know which CDN URL to request.

This ensures:

Access control: Facebook can revoke access by not returning the URL
Analytics: Facebook tracks who watches what
Flexibility: Facebook can switch CDN providers without users noticing

Next: How CDN request routing works with Anycast and GeoDNS.