System Design — Bài 6: Đường đi của request: DNS, CDN, Load Balancer và Gateway

Trước khi vào code nghiệp vụ, một request có thể đã được trả ngay từ bộ nhớ trình duyệt hoặc CDN. Biết từng vai trò giúp bạn giải thích cả đường đi nhanh lẫn trường hợp phải tới origin, đồng thời tránh đặt nhầm DNS vào chuỗi chuyển tiếp HTTP.

Khóa học System Design: mục lục 21 bài — bạn đang đọc bài 6.

DNS — trạm đầu tiên của mọi request

DNS, Domain Name System, giúp phân giải tên miền thành thông tin địa chỉ. Khi trình duyệt đã có kết quả còn hợp lệ trong cache, nó không cần thực hiện toàn bộ quá trình phân giải lại cho mỗi request.

TTL mô tả thời gian kết quả được phép giữ trong cache. TTL dài giảm số lần hỏi nhưng có thể làm thay đổi địa chỉ lan chậm hơn. TTL ngắn giúp cập nhật nhanh hơn trong điều kiện phù hợp, đổi lại tăng nhu cầu phân giải. Vì nhiều tầng cache cùng tham gia, không nên coi đổi DNS là cách chuyển traffic tức thời tuyệt đối.

GeoDNS có thể trả địa chỉ dựa trên thông tin vị trí hoặc chính sách. Sau khi phân giải, client mới gửi HTTP tới địa chỉ nhận được; DNS thường không nằm trên đường truyền nội dung của request đó.

Load Balancer — biến nhiều máy thành một hệ thống

Load balancer phân phối traffic tới nhiều backend. Round robin luân phiên qua các máy. Least connections dựa vào số kết nối, nhưng số kết nối chỉ là đại diện cho tải; một kết nối nhàn rỗi khác một kết nối đang xử lý nặng. Hash theo client giúp ổn định đích đến nhưng có thể tạo lệch tải.

Health check giúp loại backend không khỏe. Vẫn có cửa sổ phát hiện lỗi và request đang bay có thể thất bại, nên không hứa người dùng luôn hoàn toàn không nhận thấy failover. Với thao tác ghi, retry cũng cần an toàn trước request trùng.

L4 chủ yếu định tuyến theo thông tin mạng và transport. L7 hiểu giao thức ứng dụng như HTTP nên có thể chia theo path hoặc header. Chọn mức phù hợp dựa vào nhu cầu routing, kết nối và chi phí xử lý.

Reverse Proxy & API Gateway

Reverse proxy đứng phía server để nhận request thay backend. Nó có thể kết thúc kết nối mã hóa, nén hoặc cache response. Forward proxy thì đại diện phía client đi ra ngoài; điểm khác nằm ở bên mà proxy đại diện.

API Gateway tập trung các chính sách như xác thực, giới hạn tốc độ, routing và đôi khi tổng hợp response. Một sản phẩm có thể đồng thời làm reverse proxy, load balancer và gateway, nên các hộp trên sơ đồ là vai trò logic chứ không luôn là ba máy riêng.

Không nên đưa mọi nghiệp vụ vào gateway. Ví dụ, gateway kiểm tra token có hợp lệ, còn service đơn hàng vẫn phải kiểm tra người gọi có quyền xem đơn cụ thể đó. Nếu gateway chứa toàn bộ quy tắc nghiệp vụ, nó dễ trở thành điểm khó thay đổi và phụ thuộc chung.

CDN — đẩy nội dung về gần người dùng

CDN, Content Delivery Network, dùng các điểm phục vụ phân bố để giảm quãng đường truy cập và giảm tải origin. Ảnh sản phẩm hoặc file giao diện có thể được trả ngay từ edge nếu đã có bản cache hợp lệ.

Điểm khó là nội dung thay đổi. Với tài nguyên tĩnh, gắn phiên bản hoặc hash vào tên file giúp bản mới có địa chỉ mới. Trang HTML cần tham chiếu đúng phiên bản, còn bản cũ có thể tiếp tục tồn tại tới khi hết thời gian cache.

Không phải response nào cũng nên cache công khai. Dữ liệu cá nhân, quyền truy cập và cache key cần được thiết kế cẩn thận để tránh trả nội dung của người này cho người khác. Trong flash sale, CDN phục vụ phần trang và ảnh, còn xác nhận tồn kho vẫn cần đi qua luồng nghiệp vụ phù hợp.

Sơ đồ tổng — đường đi của một request

Đầu tiên client phân giải DNS khi cần. Sau đó request HTTP có thể tới CDN. Nếu cache trả được nội dung, đường đi kết thúc sớm. Nếu phải tới origin, traffic đi qua các vai trò cân bằng tải, gateway rồi vào service.

Service kiểm tra dữ liệu cần dùng: có thể đọc cache, truy vấn database hoặc gọi dịch vụ khác. Response quay về theo đường tương ứng. Đây là một mô hình minh họa; hệ nhỏ có thể gộp nhiều vai trò, hệ khác có đường riêng cho upload hoặc kết nối realtime.

Khi trình bày, hãy lần theo một thao tác cụ thể thay vì đọc tên tất cả các hộp. Với mỗi điểm dừng, nói dữ liệu vào là gì, dữ liệu ra là gì và nếu thành phần đó lỗi thì điều gì xảy ra. Như vậy sơ đồ mới thể hiện hành vi.

Tách đường phân giải và đường dữ liệu

Phân giải khi cần:
Client --hỏi tên miền--> DNS --trả địa chỉ--> Client

HTTP(S):
Client -> CDN --cache hit--> Response
           |
        cache miss
           v
       LB/Gateway -> Service -> Cache / Database

LB, reverse proxy và gateway là vai trò logic, có thể cùng một sản phẩm. Với response cá nhân, cần cache policy và cache key phù hợp. Service vẫn kiểm tra quyền trên tài nguyên cụ thể sau khi gateway xác thực người gọi.

Thuật ngữ cần nhớ

• DNS — Domain Name System: Hệ thống tên miền: phân giải tên sang bản ghi như địa chỉ máy đích; đây là bước tra cứu, không phải trạm chuyển tiếp request web.

• CDN — Content Delivery Network: Mạng phân phối nội dung: đưa nội dung tới các máy biên gần người dùng để giảm độ trễ và tải về máy chủ gốc.

• TTL — Time To Live: Thời gian sống còn hiệu lực của dữ liệu, bản ghi tên miền hoặc lease. Hết hạn không tự thực hiện nghiệp vụ như hoàn tồn kho; cần luồng xử lý tương ứng.

• L4 — Layer 4 — Transport Layer: Tầng vận chuyển trong mô hình mạng; cân bằng tải ở mức kết nối, thường dựa trên địa chỉ và cổng, không đọc đường dẫn web.

• L7 — Layer 7 — Application Layer: Tầng ứng dụng; proxy/cân bằng tải có thể đọc host, path hoặc header để định tuyến theo nội dung request.

Bài tập tự thực hành

Vẽ đường đọc ảnh cache hit và đường API cache miss.

Gợi ý kiểm tra lời giải

DNS là phân giải; hit có thể dừng ở edge; miss tới origin; có chính sách cache dữ liệu cá nhân.

Tự kiểm tra sau bài học

• DNS xuất hiện ở đường phân giải, không chuyển tiếp HTTP.

• Chỉ rõ request nào dừng ở edge, request nào tới origin.

• Nêu hành vi retry và kiểm tra quyền khi backend lỗi.

Tiếp tục lộ trình

Bài trước — Performance và availability: đo đúng, tối ưu đúng

Bài tiếp — Chọn database từ access pattern: ACID, index, B+Tree và LSM

Xem toàn bộ khóa học System Design 21 bài