Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là BA cho một sàn thương mại điện tử ở TP.HCM. Sản phẩm chạy ngon trong lúc demo nội bộ, nhưng đến ngày khuyến mãi lớn, đội marketing kéo về 50.000 khách cùng lúc, và bộ phận chăm sóc khách hàng bắt đầu nhận hàng loạt phàn nàn: "Trang load chậm quá", "Ảnh sản phẩm hiện cả phút mới ra", "Khách ở Cần Thơ vào còn chậm hơn ở Sài Gòn". Lúc này, nếu bạn không hiểu CDN là gì, bạn sẽ ngồi yên trong cuộc họp khẩn cấp trong khi đội kỹ thuật bàn về "edge", "cache hit ratio", "origin offload" — toàn những từ nghe quen mà không nắm được.
CDN (Content Delivery Network) là một trong những thành phần hạ tầng phổ biến nhất nhưng cũng dễ bị BA bỏ qua nhất, vì nó "vô hình" — không có màn hình nào để click, không có nút nào để bấm. Nhưng chính lớp vô hình này quyết định trải nghiệm tốc độ của người dùng, chi phí băng thông của công ty, và cả độ ổn định của hệ thống khi có lưu lượng lớn. Là BA, bạn không cần cấu hình CDN bằng tay, nhưng bạn cần hiểu nó đủ để: viết requirement chính xác, ước lượng chi phí, đặt câu hỏi đúng cho đội kỹ thuật, và giải thích cho stakeholder vì sao "trang chậm ở miền Tây" lại liên quan đến một mạng lưới server đặt rải rác khắp nơi.
Bài này tập trung riêng vào CDN và edge network cho static assets. Các chủ đề liên quan như chiến lược cache (TTL, write-through) hay load balancer phân phối traffic sẽ được nói sâu ở các bài khác — ở đây chúng ta chỉ đụng đến chúng đủ để hiểu bức tranh.
Khái niệm cốt lõi
CDN là gì — giải thích bằng hình ảnh đơn giản
CDN là một mạng lưới các server đặt rải rác về mặt địa lý, lưu sẵn (cache) các bản sao nội dung của bạn ở nhiều nơi trên thế giới. Mục tiêu chỉ có một: đưa nội dung đến gần người dùng nhất có thể, để giảm độ trễ (latency).
Hãy hình dung không có CDN. Server gốc (origin) của bạn đặt ở một trung tâm dữ liệu tại Singapore. Một khách hàng ở TP.HCM mở trang web — request phải đi từ HCM ra Singapore, server xử lý, rồi gửi dữ liệu ngược về. Quãng đường vật lý này tốn thời gian, và càng xa thì càng chậm.
Bây giờ có CDN. Nhà cung cấp CDN đặt sẵn các edge server (server biên) ở nhiều thành phố, trong đó có một điểm ngay tại TP.HCM (gọi là PoP — Point of Presence). Lần đầu khách HCM truy cập, edge HCM chưa có nội dung nên nó lấy từ origin Singapore về, lưu lại bản sao. Từ lần thứ hai trở đi, mọi khách ở HCM đều được phục vụ ngay từ edge HCM:
Không có CDN:
User HCM ──────────────────> Origin Singapore (~80ms mỗi chiều)Có CDN (lần 2 trở đi):
User HCM ──> CDN edge HCM (~5ms) [nội dung đã cache sẵn ở đây]
Sự khác biệt giữa 80ms và 5ms nghe nhỏ, nhưng nhân với hàng chục file (ảnh, CSS, JavaScript, font) mà mỗi trang phải tải, nó cộng dồn thành cảm giác "nhanh" hay "ì ạch" rất rõ ràng.
Static assets — thứ mà CDN phục vụ tốt nhất
Không phải mọi thứ đều cache được trên CDN. CDN sinh ra để phục vụ static assets — những file không thay đổi theo từng người dùng:
- Ảnh, video, file PDF
- File CSS (định dạng giao diện), JavaScript (logic phía trình duyệt)
- Font chữ
- File tải về (app, tài liệu)
Ngược lại, dynamic content (nội dung động) — như trang "Đơn hàng của tôi", số dư ví, giỏ hàng cá nhân — thay đổi theo từng người, không thể cache chung được. Loại này thường vẫn phải về origin. (CDN hiện đại có cơ chế xử lý dynamic thông minh hơn, nhưng phần lõi giá trị của CDN vẫn nằm ở static assets.)
Là BA, khi viết spec bạn nên phân loại rõ: tài nguyên nào là static (đẩy lên CDN được) và tài nguyên nào là dynamic (phải xử lý ở origin). Đây là một trong những phân biệt thực dụng nhất bạn mang vào bàn thiết kế.
Cache hit, cache miss và origin offload
Ba thuật ngữ bạn chắc chắn sẽ nghe:
- Cache hit: edge server đã có sẵn nội dung, phục vụ ngay — nhanh, không làm phiền origin.
- Cache miss: edge chưa có, phải đi lấy từ origin về — chậm hơn, nhưng chỉ xảy ra lần đầu hoặc khi cache hết hạn.
- Cache hit ratio: tỉ lệ phần trăm số request được phục vụ từ cache. Tỉ lệ này càng cao càng tốt. Một hệ thống tối ưu thường đạt 85–95% cho static assets.
TTL — nội dung sống bao lâu trong cache
Mỗi nội dung cache có một TTL (Time To Live) — thời gian nó được coi là "còn tươi" trước khi edge phải kiểm tra lại với origin. Ảnh logo có thể đặt TTL 30 ngày (vì gần như không đổi), còn file giá khuyến mãi có thể chỉ vài phút. Chi tiết về chiến lược cache là chủ đề của bài riêng, nhưng bạn cần biết: TTL quá dài thì khách thấy nội dung cũ sau khi bạn đã cập nhật; TTL quá ngắn thì cache miss nhiều, mất tác dụng của CDN. Khi nội dung thay đổi gấp, đội kỹ thuật dùng thao tác purge / cache invalidation để xóa bản cũ khỏi tất cả edge ngay lập tức.
Lợi ích CDN — tóm gọn cho stakeholder
- Tốc độ: giảm latency vì nội dung ở gần người dùng.
- Giảm chi phí hạ tầng: origin offload, server gốc nhỏ hơn.
- Chịu tải tốt: lưu lượng lớn được hấp thụ bởi mạng edge, tránh sập origin.
- Tăng độ tin cậy: nếu origin gặp sự cố tạm thời, edge vẫn phục vụ bản cache (tùy cấu hình).
- Bảo mật biên: nhiều CDN tích hợp sẵn chống tấn công DDoS và lọc lưu lượng độc hại ngay tại edge.
Tình huống thực tế
Tình huống 1: Sàn thương mại điện tử và ngày Sale 12/12
Một công ty thương mại điện tử giả định tên ChợViệt đặt origin server tại Singapore. Ngày thường họ phục vụ khoảng 20.000 lượt truy cập/ngày, mọi thứ ổn. Đến đợt Sale 12/12, marketing đẩy traffic lên gấp 15 lần trong vài giờ cao điểm.
Trước khi dùng CDN, mỗi ảnh sản phẩm — và một trang danh mục có thể chứa 40–60 ảnh thumbnail — đều phải tải từ Singapore về. Khách ở các tỉnh xa như Cà Mau, Lào Cai chịu latency cao nhất, trang load mất 6–8 giây, nhiều người bỏ giỏ hàng. Server origin thì nghẽn vì phải gửi cùng một tập ảnh hàng triệu lần.
Sau khi đưa toàn bộ ảnh, CSS, JS lên CDN với PoP tại HCM và Hà Nội, kết quả thay đổi rõ: cache hit ratio đạt ~92%, nghĩa là origin chỉ còn phải xử lý 8% lưu lượng ảnh. Thời gian load trang giảm từ 6–8 giây xuống còn dưới 2 giây ở hầu hết các tỉnh. Quan trọng với bộ phận tài chính: vì origin được offload, họ không cần nâng cấp gấp gói server đắt tiền cho mỗi đợt sale.
Bài học rút ra: CDN không chỉ là chuyện tốc độ, mà là chuyện chịu tải lúc cao điểm mà không phải phình to hạ tầng. Là BA, khi viết requirement cho một sự kiện lưu lượng lớn, hãy đưa "static assets phải phục vụ qua CDN" thành một dòng yêu cầu phi chức năng rõ ràng.
Tình huống 2: Ứng dụng học trực tuyến phục vụ cả Đông Nam Á
Một nền tảng e-learning giả định tên EduSEA có học viên ở Việt Nam, Indonesia, Philippines và Thái Lan. Nội dung nặng nhất của họ là video bài giảng — mỗi video vài trăm MB, và hàng nghìn học viên xem cùng lúc vào buổi tối.
Ban đầu họ stream video trực tiếp từ origin ở Việt Nam. Học viên ở Jakarta và Manila phàn nàn video giật, phải buffer liên tục, vì đường truyền quốc tế vừa xa vừa nghẽn. Đội kỹ thuật chuyển sang dùng CDN có PoP rải khắp khu vực: học viên Jakarta được phục vụ từ edge Jakarta, học viên Manila từ edge Manila.
Kết quả: trải nghiệm xem video mượt hẳn ở mọi nước, vì mỗi video chỉ cần đi quãng đường quốc tế một lần (từ origin về edge khu vực), sau đó hàng nghìn học viên trong khu vực đó dùng chung bản cache. Băng thông quốc tế đắt đỏ của origin giảm mạnh.
Bài học rút ra: với nội dung nặng và người dùng phân tán địa lý, CDN gần như là bắt buộc. BA cần nhận ra "người dùng ở nhiều quốc gia" là một tín hiệu sớm để đưa CDN vào kiến trúc ngay từ đầu, thay vì vá víu sau khi có phàn nàn.
Tình huống 3: Cập nhật banner nhưng khách vẫn thấy bản cũ
Một ngân hàng số giả định tên VBank thay banner khuyến mãi trên app. Marketing báo đã đẩy ảnh mới lên lúc 9h sáng, nhưng đến trưa khách vẫn chụp màn hình gửi về kêu thấy banner cũ. Đội marketing hoảng, tưởng có lỗi nghiêm trọng.
Nguyên nhân hóa ra rất CDN: file banner cũ được đặt TTL 7 ngày trên edge. Dù origin đã có ảnh mới, các edge server vẫn phục vụ bản cũ cho đến khi hết TTL. Cách xử lý là đội kỹ thuật chạy cache purge để xóa banner cũ khỏi mọi edge, hoặc dùng kỹ thuật đổi tên file (cache busting) cho mỗi phiên bản — ví dụ banner-v2.jpg thay vì ghi đè banner.jpg.
Bài học rút ra: CDN tăng tốc nhưng cũng tạo ra "độ trễ cập nhật". Khi BA viết spec cho nội dung thay đổi thường xuyên (banner, giá, thông báo), phải hỏi rõ: nội dung này được cache bao lâu, và khi cần đổi gấp thì purge bằng cách nào? Bỏ qua câu hỏi này dễ dẫn đến khủng hoảng truyền thông nhỏ như trên.
Hướng dẫn từng bước
Dưới đây là cách một BA tiếp cận CDN trong một dự án thực tế, từ góc nhìn phân tích chứ không phải cấu hình kỹ thuật:
- Phân loại tài nguyên static vs dynamic. Lập một bảng liệt kê mọi loại nội dung sản phẩm phục vụ: ảnh, video, CSS/JS, font (static) và trang cá nhân hóa, API trả dữ liệu riêng từng người (dynamic). Đánh dấu rõ cái nào ứng viên cho CDN.
- Xác định người dùng ở đâu. Phân bố địa lý của người dùng quyết định CDN có cần thiết không và cần PoP ở đâu. Toàn bộ người dùng trong nội thành một thành phố thì lợi ích CDN nhỏ; người dùng trải khắp quốc gia hoặc khu vực thì lợi ích lớn.
- Ước lượng lưu lượng và đỉnh tải. Làm việc với đội kỹ thuật và marketing để ước số request, dung lượng truyền (GB/tháng), và các sự kiện cao điểm. Đây là dữ liệu để ước chi phí CDN, vốn thường tính theo lượng dữ liệu truyền ra (egress).
- Đặt yêu cầu về độ tươi của nội dung. Với mỗi loại static asset, ghi rõ kỳ vọng: ảnh sản phẩm cập nhật trong bao lâu thì chấp nhận được? Banner cần đổi tức thì không? Thông tin này giúp đội kỹ thuật chọn TTL và chiến lược purge.
- Viết yêu cầu phi chức năng (NFR). Ví dụ: "Static assets phải được phục vụ qua CDN với cache hit ratio mục tiêu ≥ 90%", "Thời gian tải trang danh mục ≤ 2 giây ở các tỉnh thành lớn", "Khi cập nhật banner, nội dung mới phải hiển thị trong vòng 5 phút".
- Làm rõ cơ chế cập nhật khẩn. Hỏi đội kỹ thuật: khi cần thay nội dung gấp, dùng purge hay cache busting? Quy trình ai được quyền kích hoạt purge?
- Theo dõi chỉ số sau khi vận hành. Đưa vào yêu cầu báo cáo các chỉ số: cache hit ratio, thời gian load theo vùng, chi phí băng thông CDN. Đây là bằng chứng để đánh giá ROI của khoản đầu tư CDN.
Lỗi thường gặp & mẹo
Lỗi: Tưởng CDN cache được mọi thứ. Nhiều BA viết "đưa toàn bộ hệ thống lên CDN cho nhanh". Sai. CDN chỉ tỏa sáng với static assets. Nội dung cá nhân hóa, dữ liệu nhạy cảm theo từng người vẫn phải xử lý ở origin. Mẹo: luôn phân loại static/dynamic trước khi nói đến CDN.
Lỗi: Quên chuyện "nội dung cũ". Đẩy lên CDN rồi quên rằng cache làm chậm cập nhật. Hậu quả là khách thấy giá cũ, banner cũ. Mẹo: với mọi nội dung hay đổi, hỏi rõ TTL và quy trình purge ngay từ khâu spec.
Lỗi: Cache nhầm dữ liệu cá nhân. Tình huống nguy hiểm nhất: cấu hình sai khiến CDN cache một trang chứa thông tin riêng của người A rồi phục vụ cho người B. Đây là sự cố bảo mật thật, từng xảy ra ở nhiều hệ thống lớn. Mẹo: BA phải nêu rõ trang nào là cá nhân hóa và tuyệt đối không được cache công khai.
Lỗi: Bỏ qua chi phí egress. CDN không miễn phí; chi phí thường tính theo dung lượng truyền ra. Một video viral có thể tạo hóa đơn bất ngờ. Mẹo: đưa ước lượng lưu lượng vào tính toán chi phí ngay từ đầu.
Mẹo nâng cao: cache busting bằng đổi tên file. Thay vì ghi đè style.css, dùng style.a3f9.css (chuỗi băm theo nội dung). Mỗi lần đổi nội dung, tên file đổi, trình duyệt và CDN tự coi là file mới — không cần purge. Đây là kỹ thuật rất phổ biến, BA nên biết để hiểu vì sao đội dev hay nhắc đến "versioned assets".
Mẹo giao tiếp stakeholder: khi giải thích CDN cho người không kỹ thuật, dùng phép so sánh kho hàng: thay vì mọi đơn hàng đều gửi từ một kho trung tâm tận Singapore, bạn đặt sẵn hàng ở các kho nhỏ tại từng tỉnh, ai đặt thì lấy ngay từ kho gần nhất. Hình ảnh này gần như ai cũng hiểu ngay.
Bài tập thực hành
- Phân loại tài nguyên. Chọn một ứng dụng bạn quen (ví dụ một app đặt đồ ăn). Liệt kê 10 loại nội dung của nó và đánh dấu cái nào là static (CDN được), cái nào là dynamic (về origin). Giải thích ngắn lý do cho từng cái.
- Viết NFR. Soạn 3 yêu cầu phi chức năng liên quan đến CDN cho một sàn thương mại điện tử chuẩn bị sự kiện sale lớn. Mỗi yêu cầu phải đo lường được (có con số cụ thể về thời gian, tỉ lệ, hoặc dung lượng).
- Phân tích tình huống "nội dung cũ". Một app cập nhật giá sản phẩm lúc 8h nhưng đến 10h khách vẫn thấy giá cũ. Viết một đoạn ngắn giải thích nguyên nhân có thể liên quan đến CDN và đề xuất 2 cách khắc phục.
- Câu hỏi cho đội kỹ thuật. Giả sử bạn sắp họp thiết kế với đội dev về việc thêm CDN. Soạn 5 câu hỏi bạn cần hỏi để viết spec đầy đủ (gợi ý: liên quan đến PoP, TTL, purge, chi phí, dynamic content).
- Ước lượng đơn giản. Một trang danh mục có 50 ảnh, mỗi ảnh trung bình 100KB, và có 100.000 lượt xem trang/ngày. Ước lượng tổng dung lượng truyền/ngày nếu không có CDN, rồi suy nghĩ CDN giúp giảm tải origin như thế nào (gợi ý: với cache hit ratio 90%, origin chỉ phục vụ bao nhiêu phần?).
Tóm tắt
CDN (Content Delivery Network) là mạng lưới edge server đặt rải rác địa lý, cache sẵn các bản sao nội dung để phục vụ người dùng từ điểm gần nhất, qua đó giảm latency, tăng tốc độ và giảm tải cho origin. CDN phục vụ tốt nhất cho static assets — ảnh, video, CSS, JS, font — những file giống nhau cho mọi người; còn nội dung động, cá nhân hóa vẫn phải xử lý ở origin.
Những khái niệm cốt lõi một BA cần nắm: cache hit / miss / hit ratio, origin offload (lập luận tài chính mạnh nhất), TTL quyết định nội dung sống bao lâu, và purge / cache busting để cập nhật nội dung gấp. Ba tình huống thực tế — sàn thương mại điện tử ngày sale, nền tảng học trực tuyến phục vụ cả Đông Nam Á, và sự cố banner cũ trên app ngân hàng — cho thấy CDN vừa giải quyết bài toán tốc độ và chịu tải, vừa tạo ra rủi ro "nội dung cũ" và "cache nhầm dữ liệu cá nhân" mà BA phải lường trước trong spec.
Vai trò của bạn không phải là cấu hình CDN, mà là: phân loại static/dynamic, xác định phân bố người dùng, đặt yêu cầu phi chức năng đo lường được, làm rõ cơ chế cập nhật nội dung, và lường trước rủi ro. Nắm vững những điều này, bạn sẽ tự tin ngồi trong mọi cuộc họp kiến trúc bàn về tốc độ và hạ tầng — và biết chính xác câu hỏi nào cần đặt ra.