Chương 43. CDN và edge

Ở các chương trước, ta đã gặp vài khái niệm:

  • Object storage.
  • Reverse proxy.
  • Load balancer.
  • API Gateway.

Chương này nói về một lớp khác thường đứng rất gần người dùng:

CDN.

CDN là Content Delivery Network.

Nói dễ hiểu:

> CDN là mạng máy chủ phân phối nội dung ở nhiều nơi, giúp user tải nội dung từ điểm gần họ hơn thay vì lần nào cũng quay về server gốc.

CDN đặc biệt hữu ích cho:

  • Static asset.
  • Ảnh.
  • Video.
  • File download.
  • Public content.
  • Nội dung cache được.

Nhưng CDN không phải phép màu.

Nó không tự sửa:

  • Database chậm.
  • Worker ít.
  • API cần dữ liệu realtime.
  • Permission sai.
  • Cache invalidation rối.
  • Chấm bài AI mất 90 giây.

Thông điệp chính của chương:

> CDN giúp đưa nội dung cache được ra gần user và giảm tải origin. Nhưng phải hiểu cái gì được cache, cache bao lâu, khi nào phải invalidate, và nội dung private phải được bảo vệ thế nào.

---

43.1. Ví dụ dễ hiểu: kho trung tâm và cửa hàng gần nhà

Hãy tưởng tượng một công ty bán nước.

Nếu mọi khách hàng đều phải đến kho trung tâm để lấy nước, sẽ rất chậm.

Công ty mở nhiều cửa hàng nhỏ ở các khu vực.

Khách ở Hà Nội lấy từ cửa hàng Hà Nội.

Khách ở Đà Nẵng lấy từ cửa hàng Đà Nẵng.

Khách ở Sài Gòn lấy từ cửa hàng Sài Gòn.

Kho trung tâm vẫn là nơi gốc.

Nhưng cửa hàng gần khách giúp giao nhanh hơn.

CDN cũng vậy.

Origin server/object storage:
  nơi giữ nội dung gốc.

CDN edge:
  nơi cache bản sao gần user.

User tải từ edge gần họ.

Origin bớt tải.

---

43.2. CDN giải quyết vấn đề gì?

CDN giải quyết vài vấn đề chính:

1. Giảm latency tải nội dung.

User không phải đi xa tới origin.

2. Giảm tải origin.

Nhiều request được phục vụ từ cache.

3. Giảm bandwidth origin.

File lớn không phải tải từ origin mỗi lần.

4. Tăng khả năng chịu traffic spike.

Một ảnh/video public được nhiều người xem có thể được edge phục vụ.

5. Tăng lớp bảo vệ ở cửa trước.

Một số CDN có DDoS protection, WAF, bot filtering.

CDN rất mạnh khi nội dung giống nhau cho nhiều user.

---

43.3. CDN không phải chỉ để website lớn

Nhiều người nghĩ:

CDN chỉ dành cho Facebook/YouTube/Netflix.

Không đúng.

Một app nhỏ cũng có thể dùng CDN cho:

  • JavaScript bundle.
  • CSS.
  • Logo.
  • Ảnh public.
  • File download public.
  • Landing page static.
  • Documentation.

Các dịch vụ như Cloudflare, Fastly, AWS CloudFront, Bunny CDN, Cloudflare R2 + CDN, object storage CDN integration làm chuyện này khá dễ.

Không nhất thiết phải có triệu user mới dùng CDN.

Nhưng cũng không cần dùng CDN cho mọi thứ từ ngày đầu nếu chưa có nhu cầu.

---

43.4. Origin server là gì?

Origin là nơi CDN lấy nội dung gốc khi cache chưa có hoặc cache hết hạn.

Origin có thể là:

  • App server.
  • Object storage.
  • Static hosting.
  • Image service.
  • Video service.
  • API backend.

Luồng:

Browser -> CDN edge

Nếu CDN có cache:

CDN edge -> trả response

Nếu CDN chưa có cache:

CDN edge -> Origin -> CDN edge -> Browser

Origin vẫn là nguồn thật.

CDN là lớp cache/phân phối.

---

43.5. Edge là gì?

Edge là điểm CDN gần user hơn origin.

Ví dụ user ở Việt Nam.

Origin có thể ở Singapore hoặc US.

CDN có edge gần Việt Nam.

User tải asset từ edge gần hơn.

Điều này giảm:

  • Round trip time.
  • Latency.
  • Tải lên origin.

Từ "edge" cũng được dùng rộng hơn cho edge computing, edge function, edge worker.

Nhưng trong chương này, hãy hiểu trước:

> Edge là nơi gần user, thường dùng để cache hoặc xử lý nhẹ trước khi về origin.

---

43.6. Cache hit và cache miss

Cache hit:

CDN đã có nội dung trong cache.
Trả ngay từ edge.

Cache miss:

CDN chưa có nội dung.
Phải gọi origin lấy.
Sau đó có thể cache lại.

Ví dụ:

User A tải /static/app.abc123.js
CDN miss -> lấy từ origin -> cache.

User B tải cùng file
CDN hit -> trả từ edge.

CDN hiệu quả khi cache hit cao.

Nếu mọi request đều miss, CDN không giúp nhiều.

---

43.7. Static asset

Static asset là file tĩnh như:

  • JavaScript.
  • CSS.
  • Font.
  • Logo.
  • Icon.
  • Ảnh public.

Đây là nhóm rất hợp với CDN.

Đặc biệt nếu file có tên chứa hash:

app.8f3a91.js
style.4b2c10.css
logo.a71d.webp

Khi nội dung đổi, tên file đổi.

Vì vậy có thể cache rất lâu:

Cache-Control: public, max-age=31536000, immutable

Không cần nhớ header ngay.

Ý chính:

> File versioned bằng hash có thể cache rất lâu vì khi đổi nội dung, URL cũng đổi.

---

43.8. HTML thường cache khác static asset

HTML app shell hoặc page động thường không cache lâu như asset hash.

Vì HTML có thể trỏ đến asset version mới.

Ví dụ:

<script src="/static/app.abc123.js"></script>

Khi deploy mới:

<script src="/static/app.def456.js"></script>

Nếu CDN cache HTML quá lâu, user có thể vẫn dùng version cũ.

Vì vậy thường:

HTML:
  cache ngắn hoặc revalidate.

Static asset có hash:
  cache dài.

Đây là một pattern production rất phổ biến.

---

43.9. Ảnh

Ảnh là ứng viên rất tốt cho CDN.

Ví dụ:

  • Avatar.
  • Ảnh sản phẩm.
  • Ảnh bài viết.
  • Thumbnail.
  • Cover course.
  • Public certificate image.

Ảnh thường:

  • Được nhiều người tải.
  • Tốn bandwidth hơn JSON.
  • Có thể resize/convert.
  • Không cần đổi liên tục.

Pattern tốt:

User upload ảnh gốc
-> object storage private/tmp
-> worker validate/resize/convert
-> tạo các bản public/private phù hợp
-> CDN phục vụ bản đã xử lý

Không nên dùng ảnh gốc 8 MB cho mọi thumbnail.

CDN giúp phân phối.

Nhưng bạn vẫn cần tạo kích thước/format hợp lý.

---

43.10. Image optimization ở edge

Một số CDN hỗ trợ tối ưu ảnh:

  • Resize.
  • Convert WebP/AVIF.
  • Quality adjustment.
  • Format theo browser.
  • Cache variant.

Ví dụ:

/image.jpg?width=400

CDN tạo/cache bản 400px.

Điều này rất hữu ích nếu app có nhiều ảnh.

Nhưng cần kiểm soát:

  • Kích thước cho phép.
  • Số biến thể.
  • Chi phí.
  • Cache key.
  • Không để user tạo vô hạn variant.

Nếu cho bất kỳ width/height nào:

?width=1
?width=2
?width=3
...

CDN có thể bị tạo rất nhiều bản cache.

---

43.11. Video

Video là bài toán lớn hơn ảnh.

CDN rất quan trọng cho video vì:

  • File lớn.
  • Nhiều người xem.
  • Bandwidth cao.
  • User ở nhiều vùng.

Nhưng video production thường cần thêm:

  • Transcoding.
  • HLS/DASH.
  • Nhiều bitrate.
  • Thumbnail.
  • Subtitle.
  • DRM nếu cần.
  • Player phù hợp.

CDN chỉ phân phối video nhanh hơn.

Nó không tự biến một file mp4 upload thô thành streaming platform tốt.

Với sản phẩm video nghiêm túc, nên cân nhắc managed video service.

---

43.12. File download

CDN cũng hữu ích cho file download:

  • PDF public.
  • Report public.
  • Installer.
  • Dataset public.
  • Course material public.
  • Export public tạm thời.

Nếu file private, cần protected content.

Không nên chỉ đưa file private lên CDN public rồi hy vọng URL khó đoán là đủ.

Với file public:

Object storage -> CDN -> Browser

Với file private:

Backend kiểm tra quyền
-> tạo signed URL/signed cookie
-> Browser tải qua CDN/object storage

---

43.13. Cache-Control

Cache-Control là header nói browser/CDN nên cache thế nào.

Ví dụ:

Cache-Control: public, max-age=3600

Nghĩa là:

Có thể cache public trong 3600 giây.

Một số directive hay gặp:

public
private
no-store
no-cache
max-age
s-maxage
immutable
stale-while-revalidate

Không cần thuộc hết ngay.

Nhưng cần hiểu:

> Cache behavior nên được điều khiển rõ bằng header hoặc rule CDN, không nên để mặc định mơ hồ.

---

43.14. Public cache và private cache

Public cache:

Nội dung giống nhau cho mọi người.
CDN được cache.

Ví dụ:

  • Logo.
  • JS/CSS.
  • Ảnh public.
  • Landing page public.

Private cache:

Nội dung riêng cho một user.
Không nên cache public ở CDN.

Ví dụ:

  • Dashboard cá nhân.
  • Điểm của học sinh.
  • Feedback riêng.
  • File bài nộp private.
  • Billing page.

Sai lầm rất nghiêm trọng:

Cache response private ở CDN rồi user khác đọc được.

Nếu response phụ thuộc vào cookie/user/token, phải cực kỳ cẩn thận trước khi cache ở CDN.

---

43.15. Cache key

Cache key là thứ CDN dùng để quyết định hai request có cùng cache entry không.

Cache key thường gồm:

  • URL path.
  • Query string.
  • Host.
  • Một số header nếu cấu hình.

Ví dụ:

/images/avatar.webp?width=200

khác:

/images/avatar.webp?width=800

Nếu response phụ thuộc vào:

  • Language.
  • Device.
  • Authorization.
  • Cookie.
  • Query params.

thì cache key phải tính đúng.

Nếu cache key thiếu yếu tố quan trọng, có thể trả nhầm nội dung.

Nếu cache key quá chi tiết, cache hit thấp.

Đây là trade-off.

---

43.16. Cache invalidation là gì?

Cache invalidation là làm cache cũ không còn được dùng.

Ví dụ:

Bạn đổi ảnh course.
CDN vẫn đang cache ảnh cũ.
Làm sao user thấy ảnh mới?

Có vài cách:

1. Chờ TTL hết.

Cache 1 giờ.
Sau 1 giờ tự lấy bản mới.

2. Purge/invalidate CDN.

Gửi lệnh xóa cache URL này.

3. Đổi URL.

course-cover-v1.webp
-> course-cover-v2.webp

Hoặc:

course-cover.abc123.webp
-> course-cover.def456.webp

Đổi URL thường là cách sạch nhất với static asset.

---

43.17. Vì sao đổi URL thường tốt hơn purge?

Purge cache có thể:

  • Mất thời gian lan ra các edge.
  • Có giới hạn API.
  • Sai pattern thì xóa quá nhiều.
  • Khó đồng bộ với deploy.

Đổi URL thì đơn giản:

URL mới = nội dung mới.
URL cũ = nội dung cũ.

Browser/CDN không nhầm.

Vì vậy với asset build:

app.hash.js
style.hash.css

là pattern rất tốt.

Với file user upload có thể đổi version/file_id khi nội dung đổi.

Ví dụ:

avatars/user_9/file_123.webp
avatars/user_9/file_456.webp

Database trỏ tới file hiện tại.

---

43.18. Stale content

Stale content là nội dung cache đã cũ.

Không phải lúc nào stale cũng xấu.

Ví dụ:

Ảnh public cũ hơn vài phút:
  thường chấp nhận được.

Điểm học sinh cũ:
  có thể không chấp nhận.

Phải hỏi:

Nội dung này cũ bao lâu thì ổn?

Nếu câu trả lời là:

Không được cũ.

thì CDN cache public có thể không phù hợp.

Hoặc cần revalidation/short TTL/cơ chế riêng.

---

43.19. CDN cho API response

CDN có thể cache API response, nhưng phải cẩn thận.

Hợp với:

  • Public catalog.
  • Public course preview.
  • Public article.
  • Public configuration.
  • Data ít đổi.

Không hợp hoặc rất rủi ro với:

  • Dashboard user.
  • Notification cá nhân.
  • Điểm.
  • Permission-dependent response.
  • Billing.
  • Admin API.

Nếu API response phụ thuộc vào user, token, cookie, tenant, role:

Đừng cache public bừa.

CDN API caching có thể rất mạnh.

Nhưng lỗi cấu hình có thể thành data leak.

---

43.20. CDN và logged-in pages

Logged-in pages thường chứa dữ liệu riêng.

Không nên cache public theo URL đơn giản.

Ví dụ:

/dashboard

User A và user B cùng URL nhưng nội dung khác nhau.

Nếu CDN cache /dashboard public, user B có thể thấy dashboard user A.

Với logged-in app, thường:

  • Static JS/CSS cache qua CDN.
  • API private không cache public.
  • HTML app shell có thể cache cẩn thận nếu không chứa dữ liệu private.
  • Data riêng lấy qua API có auth và no-store/private phù hợp.

Tách static app shell và data private giúp cache an toàn hơn.

---

43.21. Signed URL

Signed URL là URL có chữ ký, cho phép truy cập nội dung trong thời gian hoặc phạm vi nhất định.

Ví dụ:

https://cdn.example.com/private/report.pdf?expires=...&signature=...

CDN kiểm tra chữ ký.

Nếu hợp lệ và chưa hết hạn, cho tải.

Nếu không, từ chối.

Signed URL hữu ích cho:

  • File private.
  • Report tạm.
  • Video protected.
  • Download chỉ cho user có quyền.

Luồng:

User muốn tải report
-> Backend kiểm tra permission
-> Backend tạo signed URL
-> User tải qua CDN

Backend không phải stream toàn bộ file.

CDN/object storage gánh download.

---

43.22. Signed cookie

Signed cookie giống signed URL nhưng quyền nằm trong cookie.

Hữu ích khi user cần truy cập nhiều file trong một khu vực.

Ví dụ:

/protected/course_12/videos/*

Backend kiểm tra user có quyền học course 12.

Sau đó cấp signed cookie cho CDN.

User xem nhiều segment/video/file mà không cần signed URL riêng từng file.

Signed cookie thường dùng cho protected video/content.

Nhưng cần cấu hình cẩn thận:

  • Path scope.
  • Expiration.
  • Domain.
  • Secure/HttpOnly nếu phù hợp.
  • Revoke/short TTL.

---

43.23. Protected content không chỉ là URL khó đoán

URL khó đoán giúp một phần.

Nhưng không đủ cho private content.

Ví dụ:

/files/8f7a9c1d-report.pdf

Nếu link bị share, ai có link đều xem được nếu file public.

Protected content cần:

  • Backend kiểm tra permission.
  • Signed URL/cookie hết hạn.
  • Bucket/origin private.
  • Không list directory.
  • Không cache public sai.
  • Audit nếu nội dung nhạy cảm.

Với dữ liệu học sinh, feedback, submission:

URL khó đoán không phải permission.

---

43.24. CDN và object storage

Pattern phổ biến:

Object storage giữ file.
CDN đứng trước object storage.

Luồng:

Browser -> CDN -> Object storage

Object storage là origin.

CDN cache file ở edge.

Với public asset:

CDN public.

Với private file:

Object storage private.
CDN chỉ cho qua khi signed URL/cookie hợp lệ.

Không nên để object storage bucket public toàn bộ nếu có file private.

---

43.25. CDN có giúp upload không?

CDN chủ yếu giúp download/distribution.

Upload file lớn thường nên đi:

Browser -> Object storage trực tiếp

bằng presigned upload URL.

Một số CDN/provider có upload acceleration, nhưng ý chính vẫn là:

Đừng bắt backend app nhận file lớn nếu không cần.

CDN giúp user tải file nhanh hơn.

Object storage/direct upload giúp user upload file lớn tốt hơn.

Hai chuyện liên quan nhưng không giống nhau.

---

43.26. CDN và DDoS

Nhiều CDN giúp giảm DDoS ở tầng edge.

Vì traffic xấu bị hấp thụ/chặn trước khi về origin.

CDN có thể có:

  • Rate limit.
  • Bot protection.
  • WAF.
  • IP reputation.
  • Challenge.
  • Layer 3/4/7 protection.

Nhưng không nên nghĩ:

Dùng CDN là hết DDoS.

Nếu attacker tìm được origin IP và gọi thẳng, CDN bị bypass.

Nếu API nặng không cache được, origin vẫn có thể bị quá tải.

Cần bảo vệ origin:

  • Chỉ cho CDN/load balancer gọi origin nếu có thể.
  • Firewall/security group.
  • WAF/rate limit.
  • Không expose app server trực tiếp.

---

43.27. Origin shield

Origin shield là một lớp cache trung gian giữa edge và origin.

Ý tưởng:

Nhiều edge miss
-> cùng đi qua origin shield
-> origin nhận ít request hơn

Hữu ích khi:

  • Có nhiều edge.
  • Origin đắt hoặc yếu.
  • Traffic spike.
  • Nội dung cache được.

Không phải hệ thống nào cũng cần.

Nhưng với nội dung public lớn, origin shield có thể giảm tải origin đáng kể.

---

43.28. Cache stampede ở CDN

Cache stampede xảy ra khi cache hết hạn và nhiều request cùng lúc về origin.

Ví dụ:

Một file phổ biến hết TTL.
10.000 user request cùng lúc.
CDN miss nhiều edge.
Origin bị đập mạnh.

Cách giảm:

  • TTL hợp lý.
  • Stale-while-revalidate.
  • Origin shield.
  • Pre-warm cache nếu cần.
  • Không để nhiều nội dung hot hết hạn cùng lúc.

Cache giúp giảm tải.

Nhưng cache hết hạn cùng lúc cũng có thể tạo spike.

---

43.29. Edge function là gì?

Edge function/worker là code chạy ở edge.

Ví dụ:

  • Redirect.
  • Rewrite URL.
  • A/B test nhẹ.
  • Header manipulation.
  • Auth check đơn giản.
  • Geo routing.
  • Bot challenge.
  • Image transformation.

Ví dụ Cloudflare Workers, Fastly Compute, Lambda@Edge.

Edge function rất mạnh vì chạy gần user.

Nhưng không nên đưa logic nghiệp vụ phức tạp ra edge nếu không cần.

Vấn đề:

  • Debug khó hơn.
  • State hạn chế.
  • Runtime khác backend.
  • Data consistency.
  • Secret management.
  • Vendor lock-in.

Edge nên xử lý việc nhẹ, gần request.

Domain logic sâu vẫn nên ở backend/service.

---

43.30. Khi nào cần CDN?

CDN đáng dùng khi:

  • User ở nhiều vùng địa lý.
  • Static asset nhiều.
  • Ảnh/video/file download đáng kể.
  • Origin đang chịu bandwidth cao.
  • Cần tải trang nhanh hơn.
  • Có traffic spike cho public content.
  • Cần DDoS/WAF/bot protection ở edge.
  • Cần protected content phân phối hiệu quả.

Ví dụ:

Course cover image được hàng nghìn học sinh tải.
Feedback PDF được tải nhiều sau khi chấm.
Video bài giảng nhiều người xem.
JS/CSS bundle lớn.

CDN rất hợp.

---

43.31. Khi nào CDN không giúp được gì nhiều?

CDN không giúp nhiều nếu bottleneck là:

  • Database query chậm.
  • Worker backlog.
  • AI API latency.
  • Request phải personalized realtime.
  • Permission check nặng ở backend.
  • Cache hit thấp.
  • Nội dung đổi liên tục.
  • Upload path thiết kế sai.
  • Client chờ job nền hoàn tất.

Ví dụ AI Judge:

Mỗi bài chấm gọi AI 90 giây.

CDN không làm AI trả nhanh hơn.

Teacher dashboard query database rất nặng.

CDN chỉ giúp nếu dashboard có aggregate/cache phù hợp và không private sai cách.

Đừng dùng CDN để che bottleneck sai tầng.

---

43.32. CDN và API latency

Nếu API response không cache được, CDN vẫn có thể giúp một chút ở:

  • TLS termination gần user.
  • HTTP/2/3.
  • Connection optimization.
  • DDoS protection.
  • Routing tốt hơn.

Nhưng phần chính vẫn phải về origin.

Nếu API cần database/backend xử lý 800ms, CDN không thể biến nó thành 20ms nếu không cache.

Muốn API nhanh hơn cần:

  • Tối ưu query.
  • Cache app-level.
  • Read replica.
  • Aggregate.
  • Giảm payload.
  • Đưa computation ra job nền.

CDN không thay thế tối ưu backend.

---

43.33. CDN và SEO/performance

Với website public, CDN giúp:

  • Tải asset nhanh.
  • Giảm TTFB cho static page cache.
  • Ảnh tối ưu.
  • Giảm tải origin.
  • Cải thiện trải nghiệm người dùng ở nhiều vùng.

Nhưng performance còn phụ thuộc:

  • HTML render.
  • JS bundle size.
  • Image size.
  • Database/API.
  • Frontend hydration.
  • Third-party script.

CDN là một phần.

Không phải toàn bộ web performance.

---

43.34. CDN và cache versioning trong deploy

Một deploy frontend tốt thường:

Build asset có hash.
Upload asset lên storage/CDN.
Deploy HTML trỏ đến asset mới.
Asset cũ vẫn giữ một thời gian.

Vì user có thể đang mở HTML cũ trỏ đến asset cũ.

Nếu xóa asset cũ ngay, user có thể gặp lỗi:

404 app.oldhash.js

Vì vậy:

  • Asset hash cache dài.
  • Không xóa asset cũ ngay.
  • HTML cache ngắn/revalidate.
  • Deploy atomic nếu có thể.

CDN và deploy frontend liên quan chặt.

---

43.35. CDN log

CDN có log riêng.

Log có thể cho biết:

  • Cache hit/miss.
  • Edge location.
  • Status code.
  • Request path.
  • User agent.
  • Client IP.
  • Bandwidth.
  • Origin latency.
  • WAF/rate limit action.

CDN log giúp debug:

  • Vì sao origin bị tải cao?
  • URL nào miss nhiều?
  • File nào tốn bandwidth?
  • Bot nào đang scan?
  • Cache rule có hoạt động không?

Nếu không nhìn CDN log/metrics, CDN trở thành hộp đen.

---

43.36. Những lỗi CDN phổ biến

Lỗi 1:

Cache nhầm dữ liệu private.

Lỗi 2:

Cache HTML quá lâu, deploy mới không hiện.

Lỗi 3:

Không version asset, phải purge liên tục.

Lỗi 4:

Object storage bucket public cả file private.

Lỗi 5:

Signed URL sống quá lâu.

Lỗi 6:

Origin vẫn public, attacker bypass CDN.

Lỗi 7:

Image resizing tạo vô hạn variant.

Lỗi 8:

Không kiểm tra cache hit ratio.

Lỗi 9:

CDN timeout khác backend timeout gây lỗi khó hiểu.

Lỗi 10:

Cho CDN cache API dùng Authorization/Cookie mà không hiểu cache key.

---

43.37. AI Judge: CDN dùng ở đâu?

AI Judge có thể dùng CDN cho:

Frontend JS/CSS.
Logo/static images.
Course cover public.
Avatar đã xử lý nếu public/được phép.
Static docs.
Public landing page.
Feedback/report file nếu dùng signed URL.
Course material file nếu có protected content.
Video bài giảng nếu sản phẩm có video.

Không nên dùng CDN public bừa cho:

Submission source code.
Feedback private.
Điểm.
Dashboard teacher.
Student data export.
Billing/admin pages.

Những thứ private cần permission trước khi cấp quyền tải.

---

43.38. AI Judge: feedback PDF private

Ví dụ học sinh tải feedback PDF.

Luồng tốt:

1. Student gọi backend: muốn tải feedback report.
2. Backend kiểm tra:
   report thuộc submission của student này
   hoặc teacher có quyền course này.
3. Backend tạo signed CDN URL hết hạn ngắn.
4. Browser tải file qua CDN.

CDN giúp download nhanh và giảm tải backend.

Backend vẫn giữ vai trò:

Permission decision.

Không nên:

report.pdf public vĩnh viễn ai có URL cũng tải.

---

43.39. AI Judge: CDN không làm chấm bài nhanh hơn

Nếu bottleneck là:

Gemini API mất 90 giây.
Worker concurrency chỉ 4.
Queue backlog cao.

CDN không giúp.

CDN có thể giúp tải static/app/file nhanh hơn.

Nhưng chấm bài nhanh hơn cần:

  • Worker concurrency đúng.
  • Queue design.
  • Retry/backoff.
  • Rate limit/quota.
  • Prompt/model tối ưu.
  • Job status rõ.
  • Database transaction ngắn.

Đây là ví dụ kinh điển:

> Đừng dùng công cụ tầng phân phối nội dung để chữa bottleneck xử lý nền.

---

43.40. Checklist CDN

Trước khi dùng CDN, hỏi:

  • Nội dung này public hay private?
  • Có được cache ở public edge không?
  • TTL bao lâu là chấp nhận?
  • Khi đổi nội dung, invalidate bằng cách nào?
  • URL có version/hash không?
  • Cache key gồm những gì?
  • Response có phụ thuộc cookie/auth/header không?
  • Origin là app server hay object storage?
  • Origin có bị bypass trực tiếp không?
  • File private dùng signed URL/cookie chưa?
  • Signed URL sống bao lâu?
  • CDN log/metrics có bật không?
  • Cache hit ratio thế nào?
  • CDN timeout có khớp backend không?
  • Có cần image optimization không?
  • Có nguy cơ tạo quá nhiều cache variant không?

CDN tốt là CDN được thiết kế cùng dữ liệu.

Không phải chỉ bật một nút "cache everything".

---

43.41. Bảng chọn nhanh

| Tình huống | Cách nghĩ thường hợp | |---|---| | JS/CSS/font có hash | CDN cache dài | | HTML app shell | Cache ngắn/revalidate | | Ảnh public | CDN + resize/format hợp lý | | Video | CDN + transcoding/streaming, cân nhắc managed service | | File public download nhiều | CDN trước object storage | | File private | Backend permission + signed URL/cookie | | API public ít đổi | Có thể cache CDN nếu cache key rõ | | API user-specific | Không cache public bừa | | Nội dung đổi liên tục | TTL ngắn hoặc không cache | | Origin bị bandwidth cao | CDN rất đáng cân nhắc | | Worker/AI chậm | CDN không giải quyết |

---

43.42. Tóm tắt bằng AI Judge

Với AI Judge:

CDN nên phục vụ:
  frontend assets
  ảnh public
  static docs
  file download được phép
  feedback/report qua signed URL nếu private

Object storage giữ file gốc.

CDN cache/phân phối gần user.

Backend vẫn quyết định:

Ai được tải file nào?
Signed URL sống bao lâu?
File này public hay private?

CDN không giải quyết:

AI provider chậm.
Worker backlog.
Database query nặng.
Permission bug.
Job retry sai.

Điểm quan trọng:

Public content cache mạnh.
Private content phải kiểm tra quyền trước khi cấp link.

---

43.43. Kết luận của chương

CDN là một trong những công cụ thực dụng nhất để cải thiện tốc độ tải nội dung và giảm tải origin.

Nó rất hợp với static asset, ảnh, video, file download và public content.

Nó cũng có thể phục vụ protected content tốt nếu dùng signed URL/cookie và origin private.

Nhưng CDN không thay thế database optimization, queue/worker, permission, object storage design, hay backend logic.

Thông điệp cần nhớ:

> CDN là cache/phân phối ở gần user. Nó mạnh nhất với nội dung cache được. Nó nguy hiểm nhất khi bạn cache nhầm dữ liệu private hoặc không hiểu khi nào cache cũ hết hiệu lực.

Ở chương tiếp theo, ta sẽ nói về firewall, WAF và network boundary: public network khác private network ra sao, firewall/security group làm gì, WAF khác firewall ở đâu, và vì sao database/worker không nên lộ public.