Bức tranh 30 giây: Một request “đi đâu về đâu”

Bạn gõ một URL và bấm Enter. Thế là xong… nhưng phía sau nó là một chuyến du lịch ngắn.

  1. DNS trả lời: “Tên miền này trỏ tới IP nào?”
  2. Load Balancer nói: “Để tôi chọn một máy khoẻ nhất nhận request.”
  3. Web/App Server xử lý: đăng nhập, kiểm tra dữ liệu, chạy nghiệp vụ.
  4. Nếu cần dữ liệu: hỏi Cache trước (nhanh), không có thì mới hỏi Database (chuẩn).
  5. Việc nặng (gửi email, xử lý ảnh…): đẩy vào Queue, Worker làm sau.
  6. Tìm kiếm kiểu “gõ vài chữ”: gọi Search thay vì cố “vắt” Database.
  7. Ảnh/video/file: lấy từ Cloud Storage và phát qua CDN để tải nhanh.
Mẹo nhớ nhanh Hệ thống lớn lên thường vì 3 lý do: cần nhanh hơn, cần ổn định hơn, hoặc cần rẻ hơn. Mỗi “mảnh” bên dưới là một câu trả lời cho 1 trong 3 nhu cầu đó.
1

DNS : “danh bạ” của Internet

DNS giống như danh bạ điện thoại: bạn nhớ tên (domain), hệ thống tra ra số (IP). Nhờ vậy bạn đổi server/đổi IP mà người dùng vẫn vào được bằng tên miền cũ.

Dùng để làm gì?

  • Trỏ domain về server
  • Quản lý subdomain (api., img., blog.)

Khi nào bạn “đụng” tới?

  • Deploy lên production
  • Chuyển hosting / chuyển cloud

Lỗi hay gặp

  • TTL quá dài → đổi IP mà vẫn trỏ cũ
  • Nhầm record (A/CNAME) → đứt truy cập
2

Load Balancer : chia tải để hệ thống “không ngã”

Khi một máy không gánh nổi nữa, cách “đúng bài” là chạy nhiều máy song song. Load Balancer đứng ở cửa, điều phối request vào các máy phía sau.

Ví dụ dễ hiểu Một quán cà phê có 1 thu ngân: đông khách là “kẹt”. Có 3 thu ngân + 1 người phân luồng: khách đi đúng hàng, quán chạy mượt.

Lợi ích

  • Nhận được nhiều request hơn
  • 1 máy chết, hệ thống vẫn sống

Hay đi kèm

  • Health check (kiểm tra máy còn khoẻ không)
  • SSL/TLS (https) xử lý ở cửa

Cẩn thận

  • Phiên đăng nhập “dính máy” → nên làm stateless hoặc dùng store chung (vd Redis)
3

Web/App Server : nơi logic chạy thật sự

Đây là nơi nhận request và xử lý nghiệp vụ: đăng nhập, tạo đơn, lấy dữ liệu, trả HTML/JSON. Nếu coi hệ thống là nhà hàng, thì App Server là “bếp”.

Việc chính

  • Xác thực & phân quyền
  • Chạy nghiệp vụ
  • Gọi DB/cache/service

Nguyên tắc tốt

  • Ít giữ trạng thái trong RAM (stateless)
  • Log rõ ràng để dễ debug

Dấu hiệu sắp “to chuyện”

  • Deploy chậm
  • Peak traffic là timeout
  • 1 bug kéo sập cả hệ
4

Database : kho “dữ liệu chuẩn” của hệ thống

Database là nơi dữ liệu “ở lâu dài” và “đúng”. Nó mạnh ở việc lưu trữ + truy vấn có cấu trúc. Nhưng DB không thích bị hỏi đi hỏi lại cùng một câu, hoặc bắt làm nhiệm vụ không hợp (như search nâng cao, báo cáo khổng lồ).

Cảnh báo thật lòng Rất nhiều hệ thống chậm đơn giản vì: “cái gì cũng dồn vào DB”. DB nên là nguồn chuẩn, còn tốc độ và các bài toán đặc thù nên có công cụ riêng.
Tác vụ DB có hợp không? Gợi ý
CRUD (tài khoản, đơn hàng…) ✅ Rất hợp DB là “source of truth”
Đọc lặp lại dữ liệu ít đổi ⚠️ Được nhưng tốn Thêm cache
Tìm kiếm gần đúng, nhiều từ khoá ❌ Không hợp Dùng search engine
Báo cáo/BI chạy trên dữ liệu cực lớn ⚠️ Dễ ảnh hưởng prod Tách kho phân tích (DWH)
5

Cache : “nhớ tạm” để trả lời nhanh

Cache là nơi lưu tạm dữ liệu hay được hỏi. Thường nằm trên RAM nên rất nhanh. Ý tưởng đơn giản: hỏi cache trước, không có thì mới xuống DB.

Ví dụ Trang chủ hiển thị “Top sản phẩm bán chạy”. Nếu ngày đổi 1–2 lần, bạn không cần query DB mỗi lần người dùng refresh : cache là cứu tinh.

Khi nào nên dùng?

  • Đọc nhiều, ghi ít
  • Endpoint “hot” (ai cũng gọi)

Dùng kiểu gì?

  • TTL (hết hạn tự xoá)
  • Invalidate khi dữ liệu đổi

Sai lầm hay gặp

  • Dữ liệu bị cũ (quên invalidate)
  • Nhiều request cùng lúc “đập” DB khi cache hết hạn
6

Queue & Worker : việc nặng thì cho “xếp hàng”

Không phải request nào cũng cần làm xong mọi thứ mới trả về. Những việc nặng hoặc không gấp (gửi email, tạo báo cáo, resize ảnh…) nên đưa vào hàng đợi (queue), rồi để worker xử lý sau.

Cảm giác đúng khi làm đúng Người dùng bấm “Đặt hàng” → hệ thống trả “Thành công” gần như ngay. Còn email xác nhận, cập nhật kho, bắn notification… cứ từ từ chạy nền.

Lợi ích

  • Request trả nhanh
  • Chịu được traffic đột biến
  • Dễ retry khi lỗi

Thiết kế tốt

  • Job chạy lại không gây hỏng (idempotent)
  • Có nơi chứa job lỗi để điều tra

Đừng làm

  • Job quá to, không chia nhỏ
  • Không log → kẹt job là “mù”
8

Services : tách nhỏ để dễ phát triển & dễ scale

Khi hệ thống lớn lên, bạn sẽ tách theo nghiệp vụ: user, payment, product… Không phải để “cho sang”, mà để một phần gặp vấn đề không kéo cả hệ.

Quan điểm thực dụng Tách quá sớm = tốn công vận hành. Tách quá muộn = monolith đụng đâu cũng đau. Mốc hợp lý thường là khi: team đông lên + release hay xung đột + một module tăng tải nhanh.

Dấu hiệu nên tách

  • Deploy chậm, rủi ro cao
  • Module “hot” bị nghẽn
  • Team lớn, khó phối hợp release

Lợi ích

  • Deploy độc lập
  • Scale đúng chỗ nghẽn
  • Cô lập lỗi tốt hơn

Chi phí đi kèm

  • Gọi qua network (có độ trễ)
  • Quan sát hệ thống phức tạp hơn
9

Data/DWH : kho dành riêng cho phân tích

DB production sinh ra để chạy nghiệp vụ “mượt”. Còn BI/report/analytics lại thích “quét dữ liệu lớn”, join nhiều bảng, chạy lâu. Tách DWH giúp báo cáo không làm hệ thống chính chậm đi.

Phục vụ

  • Dashboard, report
  • Phân tích hành vi

Dòng chảy dữ liệu

  • ETL/ELT (trích xuất → xử lý → nạp)
  • Batch hoặc realtime

Nguyên tắc vàng

  • Đừng chạy report nặng trực tiếp DB prod
  • Metric phải thống nhất
10

Cloud Storage : chỗ để ảnh/video/file cho “đúng nghề”

File (ảnh, video, pdf…) mà lưu trong app server thì sớm muộn cũng đau đầu: backup khó, tốn dung lượng, tốn băng thông. Cloud Storage giúp lưu bền + rẻ + dễ mở rộng.

Cách làm gọn App server chỉ giữ “thông tin về file” (link, quyền truy cập, metadata). File thật nằm ở storage. Khi cần nhanh hơn nữa → gắn thêm CDN.
11

CDN : đưa nội dung tới gần người dùng

CDN là mạng lưới máy chủ đặt ở nhiều nơi. Nó “cất hộ” (cache) nội dung tĩnh như ảnh, CSS, JS… Nhờ vậy người dùng ở xa vẫn tải nhanh, và origin server đỡ bị “đập” liên tục.

CDN hợp với

  • Website/landing page nhiều traffic
  • Ảnh/video/file tải nhiều

Lợi ích

  • Giảm độ trễ
  • Giảm tải origin
  • Ổn định khi traffic tăng

Lưu ý

  • Cache có thể giữ bản cũ → cần invalidation
  • Thiết lập cache-control hợp lý

Checklist áp dụng nhanh (để đọc xong làm được)

Mục Khi nào cần Dấu hiệu “OK”
DNS Deploy/cutover Record đúng, TTL hợp lý, có plan rollback
Load Balancer Muốn chạy nhiều app server Tắt 1 máy hệ thống vẫn hoạt động
Cache DB bị đọc quá nhiều CPU/IO DB giảm rõ khi peak
Queue/Worker Request chậm vì tác vụ nền Người dùng nhận response nhanh hơn
Search Cần search “xịn” Kết quả hợp lý, autocomplete ổn
Storage + CDN File tải nhiều Ảnh/file không đi qua app server nữa
DWH Báo cáo nặng Report chạy riêng, không ảnh hưởng prod
Một lộ trình nâng cấp “đỡ đau” MVP: DNS → 1 App → 1 DB
Tăng trưởng: LB → nhiều App → Cache
Tối ưu trải nghiệm: Queue/Worker + Storage/CDN + Search
Quy mô lớn: tách Services + DWH

FAQ (ngắn gọn đúng ý)

Có cần microservice ngay không?

Thường là chưa. Lúc mới làm, monolith rõ ràng + cache/queue đúng chỗ đã giúp chạy rất tốt. Microservice chỉ nên làm khi bạn “đau thật”: deploy rủi ro, team đông, module nghẽn kéo cả hệ.

Cache có làm dữ liệu sai không?

Cache có thể trả dữ liệu cũ nếu bạn quên cập nhật hoặc TTL quá dài. Giải bằng TTL hợp lý + cơ chế invalidate khi dữ liệu đổi. Dữ liệu quan trọng vẫn dựa vào DB làm nguồn chuẩn.

Tại sao search không nên cố dùng DB?

Vì search kiểu người dùng cần (gợi ý, gần đúng, ranking…) là bài toán riêng. Search engine tối ưu việc này bằng index. DB thì tối ưu cho giao dịch và tính đúng.

Kết bài: Ta không cần thuộc tên công nghệ. Ta chỉ cần nhớ: mỗi mảnh giải một bài toán. Khi gặp hệ thống chậm/đơ, hãy tìm “nghẽn cổ chai” rồi thêm đúng mảnh.