3. From Upload to Access: Complete Chain Analysis

3.1 Three Ways to Upload Files

Method 1: Client → Server → Object Storage (Traditional Model)

Browser → Your Backend Server → Object Storage

Flow:

1. User selects a file and clicks upload
2. The file is first uploaded to your backend server
3. After receiving the complete file, the backend forwards it to object storage
4. The upload result is returned to the user

Pros:

• Simple to implement, easy to control on both frontend and backend
• Can perform file validation and format conversion on the backend
• Sensitive operations can be logged with permission checks

Cons:

• Double bandwidth consumption: User upload consumes bandwidth once, server forwarding consumes it again
• High server pressure: Large files consume significant memory and CPU
• Slow uploads: Essentially adds a relay step, extending the user-perceived upload time

Use Cases: Small files (<10MB), scenarios requiring backend processing (e.g., image compression, watermarking), internal management systems.

Method 2: Client Direct Upload to Object Storage (Modern Recommendation)

Browser ──────→ Object Storage
        ↑
        Backend only issues temporary credentials

Flow:

1. User selects a file; the frontend first requests an "upload credential" from the backend
2. The backend verifies the user's identity and requests temporary STS credentials (with expiration) from the object storage service
3. The backend returns the temporary credentials to the frontend
4. The frontend uses the credentials to directly upload the file to object storage
5. Object storage returns the upload result; the frontend notifies the backend that "upload is complete"

Pros:

• Fast uploads: No relay step, fastest user-perceived speed
• Low server pressure: Only handles credential issuance, not file streams
• Bandwidth savings: Only one upload transfer
• High security: Temporary credentials have expiration times; limited damage even if leaked

Cons:

• Slightly more complex implementation; requires understanding of STS and signing mechanisms
• Frontend needs to handle multipart uploads, resumable uploads, and other logic
• Cross-origin (CORS) configuration required

Use Cases: Large file uploads, user-generated content (UGC), businesses requiring high-concurrency uploads.

Method 3: Multipart Upload + Resumable Upload (Essential for Large Files)

10GB video file
↓
Split into 1,000 chunks of 10MB each
↓
Parallel upload (5 chunks at a time)
↓
Network drops! 600 chunks already uploaded
↓
Network recovers, resume from chunk 601
↓
All chunks uploaded, initiate "merge" request

Why multipart?

Scenario	Without Multipart	With Multipart
Network Fluctuation	99% uploaded, disconnect → restart all	Only re-upload failed chunks
Upload Speed	Single-threaded, slow	Multi-threaded parallel, fast
Memory Usage	Must buffer entire file	Only buffer current chunk
Progress Display	Only 0% and 100%	Precise progress per chunk

Multipart Specifications by Major Cloud Providers:

Provider	Chunk Size Limit	Max Chunks	Min Chunk Size
Alibaba Cloud OSS	100MB	10,000	100KB
Tencent Cloud COS	5GB	10,000	1MB
AWS S3	5GB	10,000	5MB (recommended)
Qiniu Cloud	100MB	10,000	4MB

3.2 CDN Origin Fetch Strategies Explained

What Is "Origin Fetch"?

CDN edge nodes cache content from the origin, but when:

• The content requested by the user is being accessed for the first time
• The cached content has expired (TTL elapsed)
• The cache has been manually purged/preheated

CDN nodes need to request the latest content from the origin—this process is called "origin fetch."

Three Origin Fetch Modes

Mode	Principle	Use Case	Pros/Cons
Direct Origin Fetch	CDN node → Origin	Origin has a public IP and low traffic	Simple and direct, but high origin pressure
Mid-Tier Origin Fetch	CDN node → Mid-tier → Origin	Large websites, multi-layer cache	Reduces origin pressure, complex architecture
OSS/COS as Origin	CDN node → Object Storage	Static assets, images, videos	Best practice, low cost, good performance

Origin Fetch Configuration in Practice

Scenario 1: Object Storage as Origin (Recommended)

User accesses: cdn.example.com/images/photo.jpg
                    ↓
            CDN Edge Node (Beijing)
                    ↓
            Miss, fetch from origin
                    ↓
            Origin: bucket-name.oss-cn-beijing.aliyuncs.com
                    ↓
            Returns image, CDN caches and responds to user

Key configuration items:

• Origin Type: OSS/COS domain or custom origin
• Origin Protocol: HTTP or HTTPS (HTTPS recommended)
• Origin HOST: The Host header used when accessing the origin
• Origin SNI: Server Name Indication for HTTPS origin fetch

Scenario 2: Multi-Origin Load Balancing

When a single origin can't handle the origin fetch pressure, configure multiple origins:

CDN Edge Node
    ├─ Origin A (weight 50%)
    ├─ Origin B (weight 30%)
    └─ Origin C (weight 20%)

Active/standby mode:

CDN Edge Node
    ├─ Primary Origin A (all traffic when healthy)
    └─ Backup Origin B (failover when primary fails)

Origin Fetch Bandwidth vs. CDN Bandwidth

Here's an easily confused concept:

Metric	Definition	Billing Relationship
CDN Downstream Bandwidth	Traffic from CDN nodes to users	Usually billed as CDN traffic cost
Origin Fetch Bandwidth	Traffic from origin to CDN nodes	Usually object storage or origin egress cost

Cost-Saving Tips:

• Improve CDN hit ratio (let more requests hit cache, reducing origin fetches)
• Set reasonable cache times (TTL)
• Use preheating to cache hot content before users access it
• Enable "Follow 301/302" to avoid unnecessary origin fetch redirects

3.3 Cache Strategy Configuration

Cache Key: Determining What Counts as the "Same File"

How does a CDN decide whether two requests should return the same cached copy? It relies on the cache key.

Default cache key typically includes:

• URL path (excluding query parameters)
• For example: /images/photo.jpg

Problem Scenario:

User A requests: /images/photo.jpg?w=100&h=100  (100×100 thumbnail)
User B requests: /images/photo.jpg?w=800&h=600  (800×600 large image)

If the cache key only includes the path, the two different-sized images would be treated as the same file, causing confusion.

Solution: Custom Cache Key Rules

Rule	Example	Effect
Keep specified query params	Keep w, h	Cache different sizes separately
Keep all query params	Keep all	Fully exact matching
Ignore specific query params	Ignore token, timestamp	URLs with timestamps can hit cache
Include request headers	Include Accept-Language	Return different content for different languages

Real-World Configuration Example (Alibaba Cloud CDN):

Cache key rules:
- URL path: /images/*
- Keep query params: w, h, format
- Ignore query params: token, timestamp, utm_source

Cache Time (TTL): Balancing Content "Freshness"

TTL (Time To Live) determines how long content is cached on CDN nodes. Set it too short, and you'll have many origin fetches and high costs; set it too long, and users will see stale content after updates.

Recommended TTL by File Type:

File Type	Recommended TTL	Reason
HTML pages	0-5 minutes	Frequently updated, needs real-time
JS/CSS files	1 year (with filename hash)	Content unchanged; cache invalidates when filename changes
Images/videos	7-30 days	Low update frequency, can be cached long-term
Font files	1 year	Almost never change
API responses	0-5 minutes (business-dependent)	High data real-time requirements

Best Practices for Frontend Engineering with CDN:

// webpack/vite configuration
output: {
  filename: 'js/[name]-[contenthash:8].js',
  chunkFilename: 'js/[name]-[contenthash:8].chunk.js',
}

Generated filename: app-a3f2b1c9.js

• File content changes → hash changes → new URL → natural cache invalidation
• File content unchanged → hash unchanged → URL unchanged → long-term cache hit

Cache Purge and Preheat

Manual Purge (Emergency Scenarios):

When you've updated origin content but the CDN cache hasn't expired yet, users still see the old content:

Purge Type	Effect	Time Required	Use Case
URL Purge	Invalidate cache for a specific URL	5-10 minutes	Single file update
Directory Purge	Invalidate all content under a directory	10-30 minutes	Batch update
Full-site Purge	Invalidate all cache for the entire domain	30+ minutes	Emergency rollback

Important Reminder: Purging only invalidates the cache; the next request will fetch new content from the origin. Don't do large-scale purges during peak hours, or you might overwhelm the origin.

Preheat (Proactive Optimization):

Purge is reactive (content already updated); preheat is proactive (cache in advance).

Scenario: A viral article is going live tomorrow at 10 AM

Submit preheat request tonight:
- URL: https://cdn.example.com/articles/viral-article.html
- Preheat scope: All edge nodes nationwide

Result:
When users access it at 10 AM tomorrow, the content is already waiting at edge nodes
→ Zero origin fetch latency, instant loading experience