Thư Viện Câu Hỏi Phỏng Vấn

Để tối ưu hóa thời gian tải cho các tệp tĩnh qua CDN, nhà phát triển cần cấu hình chính xác các HTTP Response Header liên quan đến caching và nén dữ liệu tại Origin Server hoặc trực tiếp trên Edge Server của CDN.

Trong quản trị hệ thống CDN, Geo-blocking và Geotargeting là hai cấu hình dựa trên vị trí địa lý của người dùng (được xác định thông qua địa chỉ IP của họ tại Edge Server).

Bản chất hiện tượng Cache Stampede

Cache Stampede xảy ra khi một tệp dữ liệu cực kỳ hot (ví dụ: một bài báo nổi tiếng hoặc một cấu hình JSON quan trọng) bị hết hạn cache (Expired) trên toàn bộ hệ thống CDN cùng một lúc.

Khái niệm SSL/TLS Termination trên CDN

Thông thường, kết nối bảo mật HTTPS diễn ra giữa Trình duyệt của người dùng (Client) và Edge Server của CDN. Quá trình giải mã mã hóa (TLS Handshake và Decryption) diễn ra tại Edge Server, được gọi là SSL Termination. Sau đó, tùy thuộc vào cấu hình, CDN có thể giao tiếp với Origin Server thông qua HTTP không mã hóa hoặc tiếp tục mã hóa bằng một kết nối HTTPS khác.

Phân biệt vị trí xử lý lỗi

1. Cấu hình tại Origin Server:
   • Khi xảy ra lỗi (ví dụ: 500 Internal Server Error, 404 Not Found), Origin Server sẽ xử lý code, render ra một trang HTML thông báo lỗi và trả về qua mạng Internet thông qua CDN đến người dùng.
2. Cấu hình tại CDN (Edge Custom Error Pages):
   • CDN chặn các mã lỗi HTTP từ Origin Server trả về (như 5xx, 4xx) ngay tại Edge Server gần nhất, và thay thế bằng một trang lỗi tĩnh được lưu trữ sẵn trực tiếp trên CDN (hoặc được fetch một lần và cache lại).

Tại sao xử lý lỗi ở tầng CDN lại tối ưu hơn?

• Giảm tải cho Origin Server (Offloading): Khi hệ thống đang gặp sự cố (ví dụ: sập database gây ra hàng loạt lỗi 500), nếu hàng triệu người dùng tiếp tục truy cập, Origin Server sẽ tiếp tục phải gánh thêm việc render trang lỗi cho từng request. Nếu dùng CDN, các Edge Server sẽ tự động trả về trang lỗi tĩnh mà không làm phiền đến Origin Server nữa, giúp hệ thống có cơ hội phục hồi.
• Trải nghiệm người dùng tốt hơn (User Experience): Trang lỗi được tải từ Edge Server gần nhất nên tốc độ hiển thị cực kỳ nhanh, ngay cả khi hạ tầng backend đang chết hoàn toàn.
• Tiết kiệm băng thông: Trang lỗi tĩnh trên CDN thường có dung lượng rất nhỏ và được nén tối ưu.

Lưu ý thực chiến cho Junior

Khi cấu hình trang lỗi tùy chỉnh trên CDN, cần lưu ý đến thời gian TTL cho cache của trang lỗi (Negative Caching). Không nên đặt TTL quá dài cho các mã lỗi như 404 nếu ứng dụng của bạn thường xuyên tạo ra các trang mới, tránh trường hợp người dùng đã tạo trang nhưng vẫn thấy báo lỗi 404 do CDN đang cache trang lỗi đó.

Sự khác biệt giữa hai mô hình cân bằng tải trong Microservices:

Để loại bỏ điểm hỏng đơn lẻ (Single Point of Failure) tại tầng Load Balancer, chúng ta không bao giờ chạy duy nhất một Load Balancer mà phải thiết kế mô hình High Availability (HA).

Để duy trì phiên làm việc (Session Persistence hoặc Sticky Sessions) qua Load Balancer, chúng ta có các giải pháp chính sau đây:

Health Check là cơ chế định kỳ mà Load Balancer gửi các tín hiệu (HTTP GET, TCP Ping) đến các Backend Server để kiểm tra trạng thái hoạt động.

SSL Termination (hoặc SSL Offloading) là quá trình giải mã (decrypt) lưu lượng HTTPS thành HTTP tại tầng Load Balancer trước khi chuyển tiếp request đến các Backend Server.

Việc sử dụng Database per Service giúp cô lập dữ liệu, đảm bảo rằng lỗi ở một dịch vụ không gây ra hiệu ứng domino (cascading failure) lên toàn bộ hệ thống. Nếu một dịch vụ gặp sự cố về database, các dịch vụ khác vẫn có thể hoạt động bình thường. Ngoài ra, nó cho phép mỗi dịch vụ lựa chọn công nghệ database phù hợp nhất với nhu cầu truy vấn, giúp tối ưu hóa hiệu năng và khả năng mở rộng độc lập.

Load Balancer tập trung vào việc phân phối lưu lượng truy cập (traffic) đến nhiều server khác nhau để tránh quá tải, đảm bảo không có server nào trở thành điểm nghẽn (bottleneck). Reverse Proxy đóng vai trò là cổng trung gian, xử lý các yêu cầu từ client trước khi chuyển tiếp vào server nội bộ. Reverse Proxy thường cung cấp thêm các tính năng như SSL Termination, Caching và tăng cường bảo mật bằng cách ẩn địa chỉ IP của server thực tế.

Khi gọi API bên thứ ba, các lỗi tạm thời như timeout hoặc network jitter là không thể tránh khỏi. Nếu gọi lại (retry) ngay lập tức, hệ thống có thể làm trầm trọng thêm tình trạng quá tải của dịch vụ đích. Exponential Backoff giúp tăng dần thời gian chờ giữa các lần thử lại, giúp dịch vụ đích có thời gian phục hồi. Ví dụ: lần thử 1 chờ 1s, lần 2 chờ 2s, lần 3 chờ 4s. Điều này giúp tăng tính ổn định và tránh bị chặn do gửi quá nhiều request trong thời gian ngắn.

Caching giúp giảm tải cho database bằng cách lưu trữ kết quả của các truy vấn thường gặp vào bộ nhớ đệm (như Redis hoặc Memcached), từ đó tăng tốc độ phản hồi và giảm áp lực lên hệ thống lưu trữ chính. Rủi ro lớn nhất là tính nhất quán của dữ liệu (Data Consistency). Khi dữ liệu gốc thay đổi nhưng cache chưa được cập nhật hoặc xóa bỏ (cache invalidation), người dùng sẽ nhận được thông tin cũ, dẫn đến sai lệch logic nghiệp vụ hoặc trải nghiệm người dùng kém.

Health Check là cơ chế để hệ thống giám sát biết được một container có đang thực sự hoạt động đúng chức năng hay không. Nếu một container đang chạy nhưng dịch vụ bên trong bị treo (deadlock), Health Check sẽ phát hiện trạng thái unhealthy. Khi đó, các orchestration tools như Kubernetes có thể tự động khởi động lại container đó để khôi phục dịch vụ. Ví dụ trong Dockerfile: HEALTHCHECK --interval=30s --timeout=3s CMD curl -f http://localhost/health || exit 1.