System Design — Tư Duy Thiết Kế Hệ Thống on Thanh HV's Blog

14.10. Search System — Phần 9 trong hành động

Mon, 13 Jul 2026 18:50:00 +0700

Case study cuối cùng có vai trò đặc biệt: Phần 9 đã cho đủ lý thuyết — bài này là bài tập tổng hợp có lời giải, đi qua đúng trình tự một team thật sẽ đi, để bạn đối chiếu với cách tự mình sẽ làm. Đọc theo cách của README Phần 14: dừng sau mỗi mục, tự trả lời trước, rồi so.

1. Business Requirement & Constraint

VietShop (Phần 12) ở giai đoạn 6+: 2M user, 800K SKU từ 10K seller. Search hiện tại là PostgreSQL ILIKE từ thời MVP — zero-result rate 22%, CTR search 11%, và đội data chỉ ra: phiên có search chuyển đổi gấp 2.3 lần phiên duyệt — nhưng search đang tệ. Bài toán được duyệt ngân sách như một dự án doanh thu, không phải dự án hạ tầng: đó là cách đúng để bài search được sinh ra.

14.9. AI Platform — GPU đắt và hai chế độ phục vụ

Mon, 13 Jul 2026 18:40:00 +0700

Bài toán định hình: tài nguyên tính toán đắt nhất từng xuất hiện trong tài liệu này (GPU inference đắt hơn CPU serving 10–100×), thời gian xử lý một request dài nhất (giây, không phải mili-giây), và output không tất định. Ba đặc điểm đó bẻ cong nhiều phản xạ đã học — nhưng phần lớn bộ công cụ cũ vẫn đúng, chỉ cần vặn lại hệ số.

1. Business Requirement & Constraint

Nền tảng AI nội bộ cho một tập đoàn bán lẻ: các team sản phẩm gọi chung một cửa để dùng LLM (chatbot CSKH, tóm tắt đánh giá, sinh mô tả sản phẩm) và các model nội bộ (phân loại ảnh, dự báo). Kết hợp API bên ngoài (OpenAI/Claude-class) và model tự host trên GPU (model tiếng Việt fine-tune, dữ liệu nhạy cảm không được rời hạ tầng). Team 8 dev/ML. Ràng buộc thống trị: ngân sách GPU + API bill — đây là hệ thống đầu tiên trong tài liệu mà chi phí biến đổi theo từng request đủ lớn để thành NFR số một.

14.8. SaaS Platform — multi-tenancy và noisy neighbor

Mon, 13 Jul 2026 18:30:00 +0700

Bài toán định hình: một hạ tầng, nghìn khách hàng, và hai lời hứa mâu thuẫn — “dữ liệu của bạn cách ly tuyệt đối” và “giá rẻ nhờ dùng chung”. Multi-tenancy là nghệ thuật giữ cả hai lời hứa cùng lúc — và tenant lớn nhất luôn lớn hơn tenant nhỏ nhất bốn bậc độ lớn (13.2 — luật lũy thừa, lần thứ n).

1. Business Requirement & Constraint

SaaS quản lý bán hàng đa kênh cho SME Việt Nam (đơn hàng, kho, khách hàng, báo cáo — kết nối sàn TMĐT): 5.000 tenant từ shop 2 người đến chuỗi bán lẻ 200 cửa hàng. Doanh thu theo gói (freemium → enterprise). Team 12 dev. Ràng buộc sống còn của mô hình SaaS: chi phí phục vụ mỗi tenant phải giảm theo quy mô — nếu mỗi khách mới cần thêm người vận hành, đó là công ty outsourcing đội lốt SaaS.

14.7. Ride Hailing — geo real-time và dữ liệu phù du

Mon, 13 Jul 2026 18:20:00 +0700

Bài toán định hình: dữ liệu trung tâm (vị trí tài xế) mất giá trị sau vài giây — lần đầu trong tài liệu này, ta gặp dữ liệu mà không lưu mới là thiết kế đúng. Cộng với matching thời gian thực theo không gian — bài toán mà index truyền thống bó tay.

1. Business Requirement & Constraint

App gọi xe khu vực (xe máy + ô tô, 3 thành phố lớn VN): khách đặt xe, hệ tìm tài xế gần, khớp lệnh, theo dõi chuyến, tính cước, surge giờ cao điểm. 50K tài xế hoạt động, 500K khách; team 15 dev. Ràng buộc nghiệp vụ khắc nghiệt: matching chậm 5 giây = khách mở app đối thủ — thị trường hai chiều, cả hai phía đều có lựa chọn khác trong túi.

14.6. Video Streaming — băng thông là kiến trúc

Mon, 13 Jul 2026 18:10:00 +0700

Bài toán định hình: video là dữ liệu nặng hơn mọi thứ khác ba bậc độ lớn — một giờ video 1080p ≈ 2–4GB, bằng vài triệu bản ghi DB. Khi dữ liệu nặng đến thế, chi phí băng thông và vị trí đặt byte quyết định kiến trúc nhiều hơn mọi lựa chọn framework.

1. Business Requirement & Constraint

Nền tảng video học tập Việt Nam (khóa học quay sẵn + livestream lớp học): giảng viên upload bài giảng, học viên xem theo gói đăng ký. 500K học viên, mục tiêu 2M. Doanh thu theo subscription → trải nghiệm xem (không giật, tua nhanh) là sản phẩm; và chi phí băng thông là dòng chi phí lớn nhất của công ty — tối ưu nó không phải tối ưu kỹ thuật mà là tối ưu biên lợi nhuận.

14.5. Banking & FinTech — khi sai một đồng là sai tất cả

Mon, 13 Jul 2026 18:00:00 +0700

Bài toán định hình: đúng tuyệt đối, chứng minh được, và kiểm toán được — trong khi throughput lại thấp một cách đáng ngạc nhiên. Banking đảo ngược trực giác của mọi case trước: đây là bài mà scale là chuyện phụ, còn từng đồng là chuyện chính.

1. Business Requirement & Constraint

Ví điện tử Việt Nam: nạp/rút qua ngân hàng, chuyển tiền P2P, thanh toán QR tại quầy. Ràng buộc đặc thù không case nào trước có: pháp lý là kiến trúc sư trưởng vô hình — giấy phép trung gian thanh toán của NHNN, đối soát bắt buộc với ngân hàng đối tác, audit trail nhiều năm, dữ liệu tại Việt Nam (1.1 §3.2). Sai lệch tiền không phải bug — là sự kiện phải báo cáo. Team 20 dev, trong đó có compliance officer ngồi trong các design review — một vị trí nói lên tất cả.

14.4. Notification System — fan-out đa kênh qua những bên không tin được

Mon, 13 Jul 2026 17:50:00 +0700

Bài toán định hình: hệ thống không sở hữu chặng cuối — mọi kênh giao (APNs/FCM, SMS, email, Zalo ZNS) đều là bên thứ ba với rate limit, sự cố và hóa đơn của họ. Notification system là bài tổng hợp đẹp nhất của Phần 6 và 13.3/13.5.

1. Business Requirement & Constraint

VietShop (Phần 12) đến lúc cần một nền tảng thông báo dùng chung: trước giờ mỗi team tự gửi (order gửi email kiểu này, marketing bắn push kiểu kia) — kết quả là user nhận 14 thông báo/ngày, không tắt được thứ mình ghét, và một chiến dịch marketing từng làm nghẽn luôn đường OTP. Bài toán thật: gom mọi thông báo về một cửa, có luật — ưu tiên, tần suất, sở thích user — và gửi tin cậy qua các kênh không tin được. Team 5 dev, phục vụ 15 team nội bộ như khách hàng.

14.3. Chat Application — triệu kết nối sống

Mon, 13 Jul 2026 17:40:00 +0700

Bài toán định hình: connection dài là state không dọn đi được — chat là nơi nguyên tắc “stateless hóa tầng app” (2.1) gặp giới hạn của nó, và phải thiết kế có state một cách kỷ luật.

1. Business Requirement & Constraint

Nền tảng chat cho thương mại (người mua ↔ shop, như chat của sàn TMĐT): hỏi hàng, trả giá, chăm sóc sau bán. Chat tốt = chốt đơn — độ trễ và độ tin của tin nhắn ảnh hưởng trực tiếp GMV. 2M user, 100K shop; team 6 dev. Ràng buộc đặc thù: shop dùng nhiều thiết bị đồng thời (app + web + nhân viên chung tài khoản), lịch sử chat là hồ sơ giao dịch — không được mất.

14.2. Social Network — fan-out và celebrity problem

Mon, 13 Jul 2026 17:30:00 +0700

Bài toán định hình: một hành động của một người phải đến với N người theo dõi — và N trải từ 3 đến 10 triệu trên cùng một hệ thống. Không có phân bố nào lệch hơn thế trong toàn bộ tài liệu này.

1. Business Requirement & Constraint

Mạng xã hội theo sở thích (cộng đồng thể thao/ẩm thực) tại Việt Nam: user đăng bài, theo dõi nhau, xem feed — dòng nội dung từ những người mình theo. Doanh thu: quảng cáo trong feed → feed là sản phẩm; nghẽn feed = nghẽn doanh thu. Team 8 dev, đã có 200K user sau viral, đang tăng 30%/tháng — bài toán không phải “thiết kế từ zero” mà là “monolith hiện tại bắt đầu oằn ở đâu”.

14.1. URL Shortener — bài tập khởi động hoàn hảo

Mon, 13 Jul 2026 17:20:00 +0700

Bài “nhỏ mà thâm”: đủ đơn giản để đi trọn chuỗi tư duy trong một chương, đủ sâu để lộ ra các quyết định thật. Đọc chương này như một bài tập mẫu về cách áp dụng chương 00 — giá trị nằm ở trình tự ra quyết định, không ở sơ đồ cuối.

1. Business Requirement & Constraint

Công ty martech Việt Nam cần rút gọn link cho các chiến dịch SMS/social của khách hàng doanh nghiệp: link ngắn tiết kiệm ký tự SMS, đo được lượt bấm, gắn được nhãn chiến dịch. Ràng buộc: team 2 dev, ra mắt trong 6 tuần, chi phí hạ tầng < $200/tháng năm đầu. Doanh thu đến từ gói SaaS theo số link + analytics — nghĩa là đếm click là tính năng ăn tiền, không phải phụ kiện.

Phần 14 — Case Studies

Mon, 13 Jul 2026 17:10:00 +0700

Mục lục

(E-commerce — case lớn nhất — là toàn bộ Phần 12; Search System đóng vai case tổng hợp của Phần 9.)

13.5. Infrastructure Failures

Mon, 13 Jul 2026 17:00:00 +0700

Năm tình huống: GC Pause, Out of Memory, DNS Failure, Region Outage, Third-party API Down. Nhóm này nhắc một sự thật hay bị quên: dưới mọi kiến trúc đẹp là máy thật, mạng thật, và những công ty khác — tất cả đều hỏng theo lịch của riêng chúng.

Case 17 — GC Pause

Triệu chứng

Latency p99/p999 có răng cưa chu kỳ trong khi p50 đẹp; service “đứng hình” 0.5–30 giây rồi sống lại như chưa có gì; hệ quả dây chuyền đặc trưng: bị văng khỏi consumer group (rebalance), mất leadership (không kịp gia hạn lease), health check fail → bị restart oan — node sống nhưng bị cả cụm đối xử như chết trong đúng khoảng pause (chương 4.4 — “chậm-như-đứt”).

13.4. Distributed Failures

Mon, 13 Jul 2026 16:50:00 +0700

Ba tình huống: Cascading Failure, Split Brain, Leader Election Failure. Đây là các sự cố “cấp hệ thống” — không thành phần nào hỏng nặng, nhưng tương tác giữa chúng giết cả hệ thống. Nền lý thuyết: Phần 4.

Case 14 — Cascading Failure

Triệu chứng

Bắt đầu bằng một sự cố nhỏ, cục bộ (một service chậm, một node chết, một deploy xấu) → lan như domino: service A chậm → upstream B cạn thread chờ A → B chậm → C cạn theo… → trong 5–15 phút, toàn hệ thống đỏ, kể cả những service không liên quan gì đến điểm khởi phát. Dashboard nhìn đâu cũng cháy — chính điều đó làm mất phương hướng.

13.3. Messaging Failures

Mon, 13 Jul 2026 16:40:00 +0700

Bốn tình huống: Kafka Lag, Message Duplication, Queue Backlog, Retry Storm. Hệ messaging đổi “fail ngay trước mặt” lấy “fail âm thầm phía sau” — sự cố của nó vì thế thường được phát hiện muộn, khi backlog đã thành núi.

Case 10 — Kafka Lag (Consumer Lag)

Triệu chứng

Dữ liệu downstream “cũ dần”: dashboard analytics trễ 40 phút, projection CQRS lệch nguồn sự thật, email gửi sau sự kiện 2 giờ. Metric consumer group lag tăng — quan trọng nhất là tăng đơn điệu không hồi.

13.2. Database Failures

Mon, 13 Jul 2026 16:30:00 +0700

Sáu tình huống: Database Hotspot, N+1 Query, Deadlock, Replica Lag, Connection Pool Exhaustion, Hot Partition. Database là nơi bottleneck ghé thăm thường xuyên nhất (chương 1.5) — và cũng là nơi sự cố khó scale-out thoát thân nhất.

Case 4 — Database Hotspot

Triệu chứng

DB tổng thể “khỏe” (CPU trung bình 40%) nhưng một nhóm thao tác cụ thể chậm bất thường; lock wait tăng; các query chạm vào một hàng/một trang cụ thể xếp hàng dài.

13.1. Caching Failures

Mon, 13 Jul 2026 16:20:00 +0700

Ba tình huống anh em: Cache Stampede, Cache Avalanche, Thundering Herd. Chung một mô hình gốc — đồng bộ hóa ngẫu nhiên + khuếch đại — khác nhau ở phạm vi và ngòi nổ.

Case 1 — Cache Stampede (dogpile trên MỘT key nóng)

Triệu chứng

Hệ thống êm ả, rồi đúng một khoảnh khắc: DB CPU dựng đứng trong vài giây, latency một nhóm endpoint tăng vọt, sau đó có thể tự hồi phục — lặp lại theo chu kỳ đúng bằng TTL của một key nào đó. Trong slow query log: hàng trăm bản sao của cùng một query trong cùng một giây.

Phần 13 — Production Failure Cases

Mon, 13 Jul 2026 16:10:00 +0700

21 tình huống sự cố production kinh điển. Mục tiêu không phải ghi nhớ từng ca — mà là nhận ra các mô hình lặp lại để khi gặp biến thể thứ 22, bạn đã có phản xạ đúng.

Cấu trúc phân tích mỗi tình huống

Mỗi failure case được phân tích theo khung 10 điểm:

Triệu chứng — những gì dashboard/user cho thấy
Root cause — nguyên nhân gốc
Tại sao xảy ra — cơ chế vật lý/logic đằng sau
Kiến trúc nào bị ảnh hưởng
Metric cần theo dõi
Dashboard — nhìn gì
Alert — ngưỡng nào
Quy trình điều tra — làm gì, theo thứ tự nào
Cách khắc phục — cầm máu ngay + chữa gốc
Cách phòng tránh

Danh mục

Nhóm	File	Các case
Caching	13.1	Cache Stampede · Cache Avalanche · Thundering Herd
Database	13.2	Database Hotspot · N+1 Query · Deadlock · Replica Lag · Connection Pool Exhaustion · Hot Partition
Messaging	13.3	Kafka Lag · Message Duplication · Queue Backlog · Retry Storm
Distributed	13.4	Cascading Failure · Split Brain · Leader Election Failure
Infrastructure	13.5	GC Pause · Out of Memory · DNS Failure · Region Outage · Third-party API Down

Bốn mô hình gốc đằng sau 21 tình huống

Đọc xong cả phần, bạn sẽ thấy hầu hết sự cố quy về bốn cơ chế:

Giai đoạn 10 — Disaster Recovery

Mon, 13 Jul 2026 16:00:00 +0700

1. Vấn đề gì xuất hiện?

VietShop giờ xử lý GMV mà mỗi giờ downtime = tiền tỷ + tổn hại thương hiệu + điều khoản phạt hợp đồng enterprise. Câu hỏi chuyển từ “làm sao để không sập” (không thể đảm bảo tuyệt đối) sang: “khi thảm họa xảy ra, chúng ta quay lại trong bao lâu, mất bao nhiêu dữ liệu, và ai làm gì?”

Thảm họa ở đây không chỉ là region cloud sập. Thống kê ngành nhiều năm cho thấy các nguyên nhân thường gặp hơn: kỹ sư chạy nhầm lệnh xóa trên production, migration hỏng dữ liệu âm thầm suốt 3 ngày, ransomware, tài khoản cloud bị khóa/xâm nhập, bug ứng dụng ghi rác lan qua replication. Lưu ý điểm chung: replication không cứu được bất kỳ ca nào trong số đó — nó trung thành nhân bản cả thảm họa.

Giai đoạn 9 — Multi-region

Mon, 13 Jul 2026 15:50:00 +0700

1. Vấn đề gì xuất hiện?

VietShop mở thị trường Indonesia và Thái Lan; đồng thời ký hợp đồng enterprise có cam kết availability cao. Ba áp lực:

Vật lý: user Jakarta gọi API đặt tại VN/Singapore: mỗi round-trip +30–70ms; một trang cần 5 round-trip là +350ms — conversion giảm đo được theo từng 100ms.
Pháp lý: một số loại dữ liệu người dùng Indonesia phải lưu tại Indonesia. Không phải bài toán hiệu năng — bài toán ranh giới dữ liệu.
Rủi ro tập trung: sự cố lớn của một cloud region (đã từng xảy ra với mọi cloud lớn) = 100% hệ thống chết. Board hỏi câu không né được: “nếu region Singapore sập một ngày thì sao?”

2. Vì sao kiến trúc cũ không còn phù hợp?

Kiến trúc một region đứng trên giả định “mọi thành phần gần nhau, round-trip ~0.5ms” — giả định thấm vào mọi thiết kế: sync replication rẻ, gọi chéo service thoải mái, một nguồn sự thật cho mọi dữ liệu. Bước ra đa region, tốc độ ánh sáng đập vỡ giả định đó: không thể có đồng thời (1) ghi latency thấp ở mọi region, (2) strong consistency toàn cầu, (3) sống sót khi mất một region — đây là PACELC (chương 4.1) hiện hình bằng tiền và mili-giây. Multi-region không phải “nhân đôi hạ tầng” — nó là chọn lại vị trí trên tam giác đó cho từng loại dữ liệu.

Giai đoạn 8 — CQRS

Mon, 13 Jul 2026 15:40:00 +0700

1. Vấn đề gì xuất hiện?

Seller dashboard (“doanh thu hôm nay, top sản phẩm, đơn chờ xử lý”) join 9 bảng, chạy 3 giây, và chạy trên cùng DB đang phục vụ checkout — mỗi lần seller F5, khách mua hàng chậm đi.
Search + filter đa chiều (giá, đánh giá, khoảng cách, khuyến mãi) là loại query mà B-tree index của OLTP không bao giờ phục vụ tốt.
Cùng một dữ liệu đơn hàng, giờ có 4 “hình dạng đọc” khác nhau: chi tiết đơn cho user, dashboard cho seller, phân tích cho ops, feature cho ML. Một schema chuẩn hóa không thể tối ưu cho cả 4 — chuẩn hóa vốn được thiết kế để tối ưu cho ghi đúng, không phải cho đọc nhanh.
Tỷ lệ đọc:ghi đo được trên các luồng này: > 100:1.

2. Vì sao kiến trúc cũ không còn phù hợp?

Một model duy nhất phục vụ hai ông chủ có yêu cầu ngược nhau: bên ghi cần chuẩn hóa, constraint, transaction, ít index (index làm chậm ghi); bên đọc cần denormalize, nhiều index, cấu trúc theo đúng hình dạng màn hình. Tối ưu cho bên này là làm hại bên kia — trên cùng một schema, cuộc giằng co này không có lời giải, chỉ có thỏa hiệp ngày càng tệ ở cả hai phía.

Giai đoạn 7 — Kafka & Event-driven Architecture

Mon, 13 Jul 2026 15:30:00 +0700

1. Vấn đề gì xuất hiện?

Sau 1 năm microservices, một dạng coupling mới mọc lên — coupling tích hợp:

Khi đơn hàng được tạo, Order service phải biết và gọi: Email, Inventory, Analytics, Loyalty, Fraud, Recommendation. Thêm consumer thứ 7 = sửa code + deploy Order service. Producer lệ thuộc vào danh sách người nghe — ngược đời.
Availability của “tạo đơn” = tích availability của 6 downstream (hoặc code retry/degrade cho từng cái, ×6).
Team Analytics muốn đi lại lịch sử đơn hàng để tính lại metric — không thể: các lời gọi HTTP đã bay hơi, dữ liệu chỉ còn trạng thái cuối trong DB.
RabbitMQ hiện tại: message tiêu thụ xong là biến mất — không phục vụ được nhu cầu “nhiều consumer độc lập, mỗi bên đọc theo nhịp riêng, replay được”.

2. Vì sao kiến trúc cũ không còn phù hợp?

Mô hình “A gọi B” (dù sync HTTP hay qua work queue) mã hóa cứng ai cần biết điều gì vào producer. Số tuyến tích hợp tăng như N×M. First principles: sự kiện nghiệp vụ (“đơn #123 đã tạo”) là một sự thật — sự thật nên được công bố một lần và ai quan tâm thì tự đến đọc, thay vì được giao tận tay từng người. Đảo ngược hướng phụ thuộc: producer không biết consumer tồn tại.

Giai đoạn 6 — Tách Microservices

Mon, 13 Jul 2026 15:20:00 +0700

1. Vấn đề gì xuất hiện?

VietShop: 1M+ user, 60 dev / 8 team, modular monolith kỷ luật tốt. Ba áp lực mới mà “một deployable” không giải được:

Nhịp deploy xung đột: team Search muốn deploy 5 lần/ngày để tune ranking; team Payments bị ràng buộc quy trình kiểm soát thay đổi nghiêm ngặt. Chung một deployable = Search bị Payments ghìm, Payments bị Search làm rủi ro.
Nhu cầu tài nguyên xung đột: Search cần máy RAM lớn + Elasticsearch; xử lý ảnh cần CPU; API thường cần nhiều instance nhỏ. Một deployable = mọi instance mang mọi thứ.
Bán kính sự cố chung: memory leak ở module khuyến mãi làm OOM cả app — gồm cả checkout. Một bug của team này đánh sập doanh thu của mọi team.

2. Vì sao kiến trúc cũ không còn phù hợp?

Modular monolith đã giải bài toán ranh giới code nhưng ba tài nguyên vẫn dùng chung không tách được: tiến trình runtime (crash chung, GC chung, leak chung), pipeline deploy (nhịp chung, rollback chung), cụm hạ tầng (shape máy chung). Khi các module cần khác nhau về runtime, nhịp deploy, hình dạng hạ tầng — chỉ tách tiến trình mới giải được. Đó chính xác là (và chỉ là) điều microservices mang lại: ranh giới deploy độc lập.

Giai đoạn 5 — Modular Monolith

Mon, 13 Jul 2026 15:10:00 +0700

1. Vấn đề gì xuất hiện?

Công ty 25 dev, 4 nhóm tính năng. Hệ thống chạy ổn — vấn đề nằm ở việc phát triển nó:

Build + test 25 phút; deploy 2 lần/tuần theo “chuyến tàu”, ai lỡ thì chờ.
Thay đổi module khuyến mãi làm gãy checkout — vì code checkout import thẳng vào class nội bộ của khuyến mãi từ 2 năm trước.
Không ai dám nói “tôi hiểu toàn bộ hệ thống”. Onboarding dev mới: 2 tháng.
Ranh giới thư mục từ giai đoạn 1 đã xói mòn: 400 điểm import chéo giữa các “module”, 60 bảng DB mà module nào cũng đọc của nhau.

Bottleneck bây giờ là coupling — đo bằng tốc độ ra feature và tỷ lệ regression liên-module, không phải bằng CPU.

Giai đoạn 4 — Thêm Message Queue

Mon, 13 Jul 2026 15:00:00 +0700

1. Vấn đề gì xuất hiện?

~200K user, GMV bắt đầu có ý nghĩa, flash sale đầu tiên sắp chạy. Ba vấn đề với queue-trên-Redis hiện tại:

Đảm bảo mỏng manh: một sự cố Redis đã làm mất ~2000 job trong 30 giây, trong đó có job cập nhật trạng thái thanh toán — team mất 2 ngày đối soát tay với cổng thanh toán.
Thiếu công cụ xử lý lỗi trưởng thành: job fail 5 lần thì đi đâu? Ai xem? Retry với backoff + dead letter + đánh chỉ mục lỗi phải tự chế.
Flash sale sắp tới: ước 10× peak vào endpoint đặt hàng trong 5 phút. Web + DB không nên (và không cần) được scale cho đỉnh 5 phút đó — cần một tầng hấp thụ spike và cho phép xử lý với tốc độ của hệ thống.

2. Vì sao kiến trúc cũ không còn phù hợp?

Redis-queue là cache được nhờ vả làm broker. Nó thiếu các thuộc tính mà bài toán mới đòi: durability có cam kết (ghi disk, replicate trước khi ack), acknowledgement chuẩn (consumer chết giữa chừng → message quay lại queue), dead letter queue, routing, priority, và backpressure rõ ràng. Vá từng thiếu hụt bằng code tự chế = tự viết một message broker tồi.

Giai đoạn 3 — Tách Background Worker

Mon, 13 Jul 2026 14:50:00 +0700

1. Vấn đề gì xuất hiện?

~100K user. Triệu chứng:

Endpoint đặt hàng p99 = 4 giây. Tracing bóc ra: logic đơn hàng 150ms, gửi email xác nhận 800ms, gọi API đối tác vận chuyển 1.2s, bắn thông báo 500ms — 2.5s là việc user không cần chờ.
Upload ảnh sản phẩm của seller treo 8–15 giây (resize 5 kích cỡ trong request).
Khi SMTP provider chậm (chuyện của họ, không phải của ta), toàn bộ endpoint đặt hàng chậm theo — độ khả dụng của ta bị xích vào bên thứ ba.
Thread/worker pool của web app cạn vào giờ peak vì bị chiếm bởi các request “treo chờ bên ngoài” → cả những endpoint nhanh cũng chờ (Little’s Law, chương 1.3).

2. Vì sao kiến trúc cũ không còn phù hợp?

Kiến trúc cũ trộn hai loại công việc có bản chất khác nhau vào một đường xử lý:

Giai đoạn 2 — Thêm Redis

Mon, 13 Jul 2026 14:40:00 +0700

1. Vấn đề gì xuất hiện?

VietShop đạt ~50K user, chạy quảng cáo tối. Triệu chứng đo được:

DB CPU 85% vào 20–22h; p99 trang chủ từ 200ms lên 2.5s đúng khung giờ đó.
pg_stat_statements chỉ mặt: 70% thời gian DB dành cho ~20 query đọc lặp lại — trang chủ, danh mục, top sản phẩm — kết quả gần như không đổi giữa hai lần chạy liên tiếp.
Tỷ lệ đọc:ghi đo được ~60:1.

2. Vì sao kiến trúc cũ không còn phù hợp?

DB đang tính lại hàng nghìn lần mỗi phút một kết quả không đổi. Vấn đề không phải PostgreSQL yếu — vấn đề là dùng công cụ đắt (query engine + disk) cho việc rẻ (nhớ lại một kết quả đã biết). Scale-up DB mua thêm thời gian nhưng đốt tiền vào đúng sự lãng phí đó; thêm read replica cũng vậy (nhân bản sự lãng phí ra N máy). First principles: dữ liệu đọc nhiều-ghi ít-chịu được trễ vài giây thuộc về RAM, nơi truy cập rẻ hơn disk 3 bậc độ lớn.

Giai đoạn 1 — Monolith + PostgreSQL

Mon, 13 Jul 2026 14:30:00 +0700

Bối cảnh

VietShop ngày 0: 3 founder (2 dev), vốn đủ sống 12 tháng, mục tiêu ra thị trường trong 2 tháng. FR: đăng ký/đăng nhập, danh mục sản phẩm, giỏ hàng, đặt hàng COD, quản trị đơn giản. NFR thật sự chỉ có hai: ra tính năng nhanh và không mất dữ liệu đơn hàng.

1. Vấn đề cần giải

Không phải scale — là tồn tại. Xác suất sản phẩm chết vì không có user cao gấp trăm lần chết vì quá nhiều user. Kiến trúc phù hợp là kiến trúc tối đa hóa tốc độ học từ thị trường trên mỗi đồng vốn.

Phần 12 — System Design Evolution

Mon, 13 Jul 2026 14:20:00 +0700

Chương quan trọng nhất của tài liệu. Mọi khái niệm ở các phần trước được đặt vào một câu chuyện duy nhất, kể từ đầu đến cuối.

Hệ thống xuyên suốt: sàn E-commerce “VietShop”

Chúng ta theo chân một sàn thương mại điện tử Việt Nam từ ngày đầu tiên đến khi phục vụ hàng chục triệu người dùng. Chọn e-commerce vì nó chứa đủ các bài toán kinh điển: read-heavy (duyệt sản phẩm), tranh chấp ghi (tồn kho), tiền bạc (không được sai), spike cực đoan (flash sale), tác vụ nền (email, ảnh), tìm kiếm, và báo cáo.

11.3. Biên phòng thủ — API Gateway, Rate Limiting, WAF

Mon, 13 Jul 2026 14:10:00 +0700

1. Problem Statement

Internet là môi trường thù địch mặc định: bot chiếm phần lớn traffic của nhiều site, credential stuffing chạy 24/7, scraper hút catalog, và thi thoảng một chiến dịch DDoS thật sự. Nếu mỗi service tự xử lý các mối lo này, ta có N bản cài đặt lệch nhau của cùng các phòng thủ (11.1 §2 — cùng lý do tập trung AuthN). Biên (edge) tồn tại để gom các mối quan tâm cắt ngang về một tuyến phòng thủ có tầng — để service phía sau tập trung vào nghiệp vụ, và để “một chỗ vá” khi có chuyện.

11.2. OAuth2, OIDC & JWT — ủy quyền và token trong hệ phân tán

Mon, 13 Jul 2026 14:00:00 +0700

1. Problem Statement

Ba bài toán token của mọi hệ hiện đại: app bên thứ ba cần truy cập dữ liệu user mà không cầm mật khẩu của user (ủy quyền — OAuth2); nhiều ứng dụng cần cùng một đăng nhập (SSO — OIDC); và N service cần xác minh danh tính người gọi mà không gọi về trung tâm mỗi request (token tự xác minh — JWT). Ba bài, một họ chuẩn — và một bãi mìn thuật ngữ nơi “dùng JWT” và “dùng OAuth” bị nói như thể là quyết định một chữ, trong khi mỗi lựa chọn con bên trong (flow nào, token sống bao lâu, thu hồi thế nào) mới là nơi an toàn được quyết định.

11.1. Authentication & Authorization — bạn là ai, bạn được làm gì

Mon, 13 Jul 2026 13:50:00 +0700

1. Problem Statement

Mọi request chạm hệ thống phải được trả lời hai câu khác nhau về bản chất: bạn là ai (Authentication — xác thực danh tính) và bạn được làm gì (Authorization — kiểm tra quyền). Trộn hai câu này — hoặc trả lời câu hai bằng niềm tin “đã qua cửa là được tất” — là gốc của lớp lỗ hổng phổ biến và tàn phá nhất trong thực tế: broken access control (nhiều năm liền đứng đầu OWASP Top 10), mà điển hình là IDOR — user A đổi order_id trên URL và đọc được đơn của user B, vì hệ chỉ hỏi “đã đăng nhập chưa” mà quên hỏi “đơn này của ai”.

Phần 11 — Security

Mon, 13 Jul 2026 13:40:00 +0700

Chủ đề: Authentication, Authorization, OAuth2, JWT, Rate Limiting, WAF, API Gateway.

Luận điểm trung tâm của phần này

Security là thuộc tính kiến trúc, không phải tính năng gắn sau — và giống durability (1.1 §9), lỗi của nó không sửa được bằng refactor: dữ liệu đã rò là đã rò. Ba nguyên tắc gốc chi phối mọi chương:

Defense in depth: nhiều lớp, không lớp nào được tin là đủ — kẻ tấn công phải vượt tất cả, còn bạn chỉ cần một lớp bắt được.
Least privilege: mọi thành phần (người, service, token) chỉ có quyền tối thiểu cho việc của nó — blast radius của một credential bị lộ tỷ lệ thuận với quyền nó mang.
Không tự chế crypto/auth: dùng chuẩn đã được soi (OAuth2/OIDC, JWT ký chuẩn, thư viện đã kiểm toán) — sáng tạo trong security là sáng tạo cách thua.

Mục lục

Bản đồ security trong toàn tài liệu

Mảnh	Ở đâu
Compliance là NFR (Nghị định 13, PCI-DSS)	1.1 §3.2
Che PII trong log/tín hiệu	10.1 §3, 10.2 §6
Backup mã hóa, immutable, chống ransomware	3.2
ACL cho topic/queue — ai được phát/nghe	6.5 §6
Idempotency chống replay nghiệp vụ	13.3
Rate limiting như công cụ reliability	13.1 — thundering herd

Phần này đứng ở góc kiến trúc sư hệ backend — identity, token, và biên — không thay thế được chuyên môn AppSec/PenTest; nó bảo đảm phần thiết kế không tạo ra những lỗ mà không PenTest nào vá nổi.

10.3. Dashboard, Alerting & On-call — từ tín hiệu đến con người

Mon, 13 Jul 2026 13:30:00 +0700

1. Problem Statement

Tín hiệu hoàn hảo (10.1) chảy qua pipeline chuẩn (10.2) vẫn chưa cứu được ai — khâu cuối là con người ra quyết định dưới áp lực lúc 3h sáng. Khâu này hỏng theo hai cách đối xứng: alert quá nhiều (người trực tê liệt, tắt thông báo, bỏ lỡ cái thật — alert fatigue là nguyên nhân gốc của nhiều sự cố kéo dài hơn là thiếu monitoring) và alert quá ít/quá trễ (khách hàng là người phát hiện sự cố). Thiết kế giao diện máy–người này là một bài thiết kế hệ thống đúng nghĩa — có SLO, có failure mode, có evolution.

10.2. OpenTelemetry & pipeline tín hiệu — thu, xử lý, lưu, trả tiền

Mon, 13 Jul 2026 13:20:00 +0700

1. Problem Statement

Ba trụ (10.1) sinh ra một dòng dữ liệu khổng lồ chảy liên tục từ mọi process — và ba câu hỏi hạ tầng: thu bằng chuẩn nào (để không viết lại instrumentation khi đổi backend), vận chuyển và xử lý ở đâu (lọc, sample, làm giàu, che nhạy cảm — trước khi trả tiền lưu), lưu vào đâu với chi phí nào. Trả lời tùy hứng ba câu này là cách các công ty tỉnh dậy với hóa đơn observability ngang hóa đơn compute và một mớ agent chồng chéo không ai dám tắt.

10.1. Ba trụ — Logging, Metrics, Tracing

Mon, 13 Jul 2026 13:10:00 +0700

1. Problem Statement

2h37 sáng, alert: “checkout error budget đang cháy”. Người trực cần trả lời ba câu theo thứ tự: có chuyện gì / ở đâu (metrics — 30 giây), chặng nào trong chuỗi 8 service (trace — 2 phút), chính xác chuyện gì đã xảy ra ở chặng đó (logs — 5 phút). Thiếu trụ nào, thời gian ở bước đó nhân 10 — MTTR là hàm trực tiếp của chất lượng ba trụ (3.1 §5 — MTTR quan trọng hơn MTBF). Chương này mổ cấu trúc từng trụ và cách chúng nối vào nhau — vì ba trụ rời rạc chỉ là ba đống dữ liệu.

Phần 10 — Observability

Mon, 13 Jul 2026 13:00:00 +0700

Chủ đề: Logging, Metrics, Tracing, OpenTelemetry, Dashboard, Alerting.

Luận điểm trung tâm của phần này

Observability là khả năng trả lời câu hỏi chưa biết trước về hệ thống từ tín hiệu nó phát ra — khác monitoring (canh các câu hỏi đã biết). Trong hệ phân tán, nó không phải tiện nghi mà là điều kiện vận hành: toàn bộ Phần 13 — mọi mục Metric/Dashboard/Alert/Điều tra — chính là phần này trong hành động.

9.3. Lựa chọn công nghệ search — khung quyết định

Mon, 13 Jul 2026 12:50:00 +0700

1. Problem Statement

“Cần search” không tự động nghĩa là “cần Elasticsearch”. Phổ lựa chọn trải từ một câu tsvector trong DB đang có, đến cụm phân tán nhiều node với nghề vận hành riêng — chênh nhau hai bậc độ lớn về chi phí trọn đời. Chọn theo thói quen (“ai cũng dùng ES”) hoặc theo sợ hãi (“PG sao làm search được”) đều bỏ qua câu hỏi đúng: workload này cần gì, và mức khiêm tốn nhất đáp ứng được là gì (5.7 §2 — cửa kiểm tra câu 3).

9.2. Kiến trúc hệ search hoàn chỉnh — indexing pipeline, query side, vận hành

Mon, 13 Jul 2026 12:40:00 +0700

1. Problem Statement

Engine tốt + analyzer tốt (9.1) chưa thành hệ search: còn phải trả lời — dữ liệu từ nguồn sự thật đến index bằng đường nào, trễ bao nhiêu, sót thì sao? Autocomplete, facet, filter — mỗi thứ cần cấu trúc gì? Reindex 50 triệu document giữa production như thế nào? Đây là phần “hệ thống” của search — nơi các bài học outbox, projection, backlog của toàn tài liệu hội tụ vào một use case.

9.1. Full-text Search — nguyên lý: inverted index, analyzer, relevance

Mon, 13 Jul 2026 12:30:00 +0700

1. Problem Statement

User gõ ao khoac nam gia re; kho có 2 triệu sản phẩm. Yêu cầu: kết quả liên quan trả trong < 100ms, khớp được dù thiếu dấu, sai chính tả nhẹ, đảo trật tự từ; và “liên quan” phải gần với “thứ user muốn mua” chứ không chỉ “chuỗi giống nhau”. LIKE '%áo khoác%' thất bại toàn tập: quét toàn bảng (không index nào giúp wildcard hai đầu), yêu cầu khớp chuỗi liên tục (đảo từ là mất), không hiểu dấu, và không có khái niệm xếp hạng. Cần một cấu trúc dữ liệu và một bộ máy ngôn ngữ sinh ra cho đúng bài này.

Phần 9 — Search

Mon, 13 Jul 2026 12:20:00 +0700

Chủ đề: Full-text Search, Elasticsearch, OpenSearch — và kiến trúc của một hệ search hoàn chỉnh.

Luận điểm trung tâm của phần này

Search tồn tại vì một khoảng trống cấu trúc: B-tree trả lời “bằng/trong khoảng”, columnar trả lời “tổng theo nhóm” — không cấu trúc nào trả lời “chứa khái niệm X, xếp theo độ liên quan” (5.7 §1 — bảng quyết định gốc). Và một sự thật nghiệp vụ: với e-commerce/marketplace/content, search là cỗ máy doanh thu — khác biệt giữa search tốt và tồi đo được bằng conversion, không phải bằng ms.

8.3. Resharding & vận hành hệ đã shard

Mon, 13 Jul 2026 12:10:00 +0700

1. Problem Statement

Mọi quyết định sharding đều sai dần theo thời gian: dữ liệu tăng 10× (4 shard thành chật), phân bố lệch dần (một shard 80% đầy trong khi anh em 30%), tenant VIP phình vượt shard của nó, hoặc — đau nhất — shard key hóa ra chọn sai (8.1 §3.2). Câu hỏi của chương này: làm sao thay đổi cách chia dữ liệu trên hệ đang chạy, không downtime, không mất ghi — bài toán được xếp vào loại khó nhất của vận hành dữ liệu, và là lý do người ta nói “shard key là cam kết hôn nhân”.

8.2. Consistent Hashing — thêm bớt node mà không xáo cả thế giới

Mon, 13 Jul 2026 12:00:00 +0700

1. Problem Statement

Hash sharding ngây thơ: node = hash(key) mod N. Đẹp cho đến ngày N đổi. Thêm node thứ 5 vào cụm 4 node: mod 4 → mod 5 — ~80% key đổi chỗ. Với cache: 80% miss đồng loạt = tự gây avalanche (13.1); với storage: di chuyển 80% dữ liệu qua mạng chỉ để thêm một máy. Mà thêm/bớt node là chuyện thường kỳ: scale theo tải, node chết, bảo trì. Cần một cách ánh xạ key → node sao cho N đổi thì chỉ ~1/N key phải dời chỗ — mức tối thiểu lý thuyết (dữ liệu phải sang node mới thì mới có ích).

8.1. Partitioning & Sharding — chia dữ liệu và cái giá của shard key

Mon, 13 Jul 2026 11:50:00 +0700

1. Problem Statement

Bảng orders của VietShop sau 4 năm: 3TB, 5 tỷ hàng. Ba loại đau cùng lúc: quản trị (backup 6 giờ, tạo index 2 ngày, xóa dữ liệu cũ bằng DELETE là bão bloat — 5.1); hiệu năng (index sâu hơn, working set vượt RAM, vacuum lê lết); và cuối cùng — trần vật lý (một máy hết cỡ để scale-up, ghi vượt năng lực single-writer — 4.2). Ba loại đau, hai lời giải khác cấp độ: partitioning trong node cho hai loại đầu, sharding ra nhiều node cho loại thứ ba. Nhầm cấp độ — sharding khi chỉ cần partition — là mua độ phức tạp lớn nhất trong nghề để chữa bệnh có thuốc rẻ.

Phần 8 — Data Partitioning

Mon, 13 Jul 2026 11:40:00 +0700

Chủ đề: Partitioning, Sharding, Consistent Hashing, phối hợp với Replication — và bài toán khó nhất: resharding hệ đang chạy.

Luận điểm trung tâm của phần này

Partitioning là câu trả lời cho câu hỏi cuối cùng của scale: khi một node không chứa nổi / phục vụ nổi toàn bộ dữ liệu thì sao? Chia dữ liệu ra N node — nhưng cái giá là mất những gì “một node” cho không: transaction toàn cục, join tùy tiện, thứ tự toàn cục, và sự đơn giản. Vì thế nguyên tắc số một, nhắc lại từ 1.5: sharding là phương án cuối, sau khi index/cache/replica/scale-up đã hết bài — và là phương án gần như không có đường lùi.

7.3. Distributed Cache — cache khi một node không đủ

Mon, 13 Jul 2026 11:30:00 +0700

1. Problem Statement

Một node Redis phục vụ ~100K ops/s và chứa được RAM của một máy (5.4). Hệ lớn vượt cả hai trần: cần triệu ops/s, cần cache working set hàng trăm GB, và cần cache sống sót khi node chết (vì mất cache = avalanche, 13.1 — với hệ hit-rate 95%, cache không còn là “tùy chọn hiệu năng” mà là thành phần sống còn). Distributed cache = chia key ra nhiều node + nhân bản — và ngay lập tức thừa hưởng mọi bài toán của Phần 4 và Phần 8: partition, hot key, rebalance, consistency giữa các tầng.

7.2. Cache Invalidation — bài toán khó thứ nhất của khoa học máy tính

Mon, 13 Jul 2026 11:20:00 +0700

“There are only two hard things in Computer Science: cache invalidation and naming things.” — câu đùa sống lâu vì nó đúng. Chương này giải thích vì sao nó khó về nguyên lý, và bộ công cụ thực dụng để sống chung.

1. Problem Statement

Nguồn sự thật thay đổi; bản sao trong cache thành nói dối. Câu hỏi: làm bản sao hết nói dối đúng lúc (đủ tươi cho nghiệp vụ) với chi phí chịu được (không biến mỗi thao tác ghi thành chiến dịch truy quét N tầng cache). Hai đầu của phổ đều dễ: không bao giờ invalidate (cache tĩnh vĩnh viễn) và invalidate mọi thứ mỗi lần ghi (tương đương không có cache). Mọi hệ thật nằm giữa — và khoảng giữa là nơi ở của race condition.

7.1. Bốn chiến lược cache — ai ghi, ai đọc, ai chịu trách nhiệm

Mon, 13 Jul 2026 11:10:00 +0700

1. Problem Statement

“Thêm cache” nghe như một quyết định — thực ra là bốn quyết định độc lập: khi miss thì ai đi lấy dữ liệu (app hay cache)? Khi ghi thì cache được cập nhật lúc nào (cùng lúc, sau, hay không bao giờ)? Ghi có chờ DB không? Và ai chịu trách nhiệm khi hai bên lệch nhau? Bốn chiến lược kinh điển là bốn tổ hợp câu trả lời — chọn sai tổ hợp cho workload là nguồn của cả bug consistency lẫn hiệu năng tồi.

Phần 7 — Caching

Mon, 13 Jul 2026 11:00:00 +0700

Chủ đề: Cache Aside, Read Through, Write Through, Write Back, Cache Invalidation, Distributed Cache.

Luận điểm trung tâm của phần này

Cache tồn tại vì hai sự thật: RAM nhanh hơn disk ~1000 lần (chương 00 §3), và truy cập dữ liệu có locality — một phần nhỏ dữ liệu nhận phần lớn truy cập (luật lũy thừa, 13.2 — hot partition là mặt tối của cùng quy luật). Không có locality, cache vô dụng; có locality, cache là đòn bẩy hiệu năng rẻ nhất trong toàn bộ hộp đồ nghề.

6.8. Outbox Pattern — móng của mọi event đáng tin

Mon, 13 Jul 2026 10:50:00 +0700

1. Problem Statement

Một thao tác nghiệp vụ cần làm hai việc trên hai hệ thống: ghi trạng thái vào database và thông báo ra ngoài (publish event lên Kafka, enqueue job, gọi webhook). Code ngây thơ:

db.commit(order) // việc 1: thành công
kafka.publish(event) // việc 2: ...crash ở đây thì sao?

Crash giữa hai dòng → hệ thống nói dối: đơn tồn tại trong DB nhưng thế giới không bao giờ biết — không email, không trừ kho, không analytics. Đảo thứ tự thì dối chiều ngược lại: event bay đi cho đơn chưa từng commit. Đây là dual-write problem — và nó không hiếm: nó xảy ra mỗi lần deploy restart process đúng khoảnh khắc đó, mỗi lần Kafka chập chờn đúng lúc DB đã commit. Không thể fix bằng try/catch hay retry — vấn đề là hai hệ thống không có transaction chung, về nguyên lý (4.4 — không có atomic commit giữa hai hệ tự trị rẻ tiền).

6.7. Saga — transaction khi không còn transaction

Mon, 13 Jul 2026 10:40:00 +0700

1. Problem Statement

Đặt hàng chạm ba service, ba database: Orders (tạo đơn), Inventory (trừ kho), Payments (trừ tiền). Trong monolith, đây là một transaction ACID — ba thao tác cùng thành công hoặc cùng biến mất, miễn phí (12.1). Tách service xong (12.6), ACID xuyên ranh giới không còn tồn tại: kho trừ rồi, tiền fail — ai trả kho về? Hệ thống kẹt ở trạng thái nửa vời mà không cơ chế nào tự dọn.

6.6. Event-driven Architecture — nghĩ bằng sự kiện

Mon, 13 Jul 2026 10:30:00 +0700

Kafka (6.5) là công cụ; event-driven là cách nghĩ. Chương này về cách nghĩ — phần khó hơn và ít được dạy hơn.

1. Problem Statement

Hệ nhiều service trưởng thành đối mặt một mâu thuẫn: nghiệp vụ đòi phản ứng dây chuyền (đơn tạo → trừ kho, cộng điểm, gửi mail, tính hoa hồng, cảnh báo fraud…) trong khi kiến trúc đòi các phần không dính nhau. Orchestration bằng lời gọi trực tiếp thỏa vế một, phá vế hai: service “đầu chuỗi” phải biết và sống chết cùng mọi service cuối chuỗi (12.7 §1). Event-driven giải mâu thuẫn bằng cách đảo chủ ngữ: thay vì A bảo B làm, A công bố điều đã xảy ra; B tự quyết định phản ứng.

6.5. Kafka — distributed log cho sự kiện

Mon, 13 Jul 2026 10:20:00 +0700

Vì-sao-tồn-tại và hành trình áp dụng đã kể ở 12.7. Chương này mổ nội thất: vì sao log lại nhanh đến thế, các đảm bảo thật sự của Kafka nằm ở đâu, và giá vận hành của chúng.

1. Problem Statement

Cần một nơi công bố sự thật đã xảy ra (order created, payment captured, price changed) sao cho: nhiều hệ tiêu thụ độc lập theo nhịp riêng, hệ đến sau đọc lại được lịch sử, thứ tự trong phạm vi cần thiết được giữ, throughput hàng trăm nghìn–triệu event/giây, và dữ liệu không mất khi máy chết. Không mô hình queue nào thỏa đồng thời các yêu cầu này — cần một mô hình khác: append-only log phân tán.

6.4. RabbitMQ — smart broker cho work queue

Mon, 13 Jul 2026 10:10:00 +0700

Bối cảnh vì-sao-tồn-tại và hành trình đưa nó vào hệ thống đã kể ở 12.4. Chương này đi sâu vào nội thất, mô hình vận hành và ranh giới của nó.

1. Problem Statement

Cần giao việc một cách tin cậy: mỗi việc đến đúng một worker, việc fail được thử lại, việc hỏng vĩnh viễn được cách ly có địa chỉ (DLQ), việc gấp vượt việc thường, spike được hấp thụ. Đây là bài toán task distribution — khác về bản chất với bài toán event distribution (Kafka, 6.5): việc thì tiêu thụ xong là xong, sự kiện thì nhiều bên cùng đọc và có thể đọc lại.

6.3. gRPC — RPC có kỷ luật cho nội bộ

Mon, 13 Jul 2026 10:00:00 +0700

1. Problem Statement

Bên trong một hệ microservices (12.6), các service gọi nhau hàng chục nghìn lần mỗi giây. Ở tần suất đó, những thứ vặt vãnh của REST/JSON thành hóa đơn lớn: serialize/parse JSON ngốn CPU thật (đo được hàng chục % CPU của service nhỏ), payload text phình băng thông, HTTP/1.1 mở nhiều connection và nghẽn head-of-line, và — đắt nhất — hợp đồng lỏng lẻo: field đổi tên, kiểu đổi, chỉ phát hiện lúc runtime bằng sự cố. Hai đầu dây đều là code của bạn; cái bạn cần không phải “phổ cập” mà là contract chặt kiểm tra lúc compile + hiệu năng + streaming — đó là gRPC.

6.2. GraphQL — client tự khai hình dữ liệu

Mon, 13 Jul 2026 09:50:00 +0700

1. Problem Statement

Ứng dụng có nhiều loại client (web, iOS, Android, smart TV, đối tác) trên cùng một domain phức tạp. Với REST thuần, mỗi màn hình gặp một trong hai bệnh: under-fetch (cần 5 resource = 5 round-trip nối tiếp — chết vì latency trên mobile 3G) hoặc over-fetch (endpoint trả 60 field, màn hình dùng 4 — chết vì băng thông). Team backend bị kẹp giữa: hoặc viết endpoint riêng cho từng màn hình của từng client (bùng nổ endpoint), hoặc bắt client chịu. GraphQL đảo quyền: schema thống nhất phía server, client tự khai chính xác hình dữ liệu nó cần, nhận về đúng hình đó trong một round-trip.

6.1. REST — hợp đồng chung của web

Mon, 13 Jul 2026 09:40:00 +0700

1. Problem Statement

Hai hệ thống của hai team (hoặc hai công ty) cần nói chuyện với nhau qua network, và hợp đồng giữa họ phải: dễ hiểu với người mới, dễ debug bằng công cụ phổ thông, tận dụng được hạ tầng web sẵn có (cache, proxy, LB, CDN), và sống sót qua nhiều năm tiến hóa mà không phá client cũ. REST không phải giao thức “tốt nhất” theo bất kỳ trục kỹ thuật đơn lẻ nào — nó là hợp đồng có hệ sinh thái lớn nhất và chi phí gia nhập thấp nhất, và đó chính là giá trị kiến trúc của nó.

Phần 6 — Communication

Mon, 13 Jul 2026 09:30:00 +0700

Chủ đề: REST, GraphQL, gRPC, RabbitMQ, Kafka, Event-driven, Saga, Outbox Pattern.

Luận điểm trung tâm của phần này

Chọn cơ chế giao tiếp là chọn hợp đồng về thời gian và lỗi — trước khi là chọn công nghệ. Ba câu hỏi định hình mọi lựa chọn trong phần này:

Bên gọi có chờ không? Sync (chờ kết quả để đi tiếp) vs async (ghi nhận ý định, kết quả đến sau). Sync dễ suy luận, giam tài nguyên theo độ trễ của bên kia; async chịu tải và cô lập lỗi, đổi bằng eventual consistency với chính nghiệp vụ của mình (12.3).
Lỗi hiện ở đâu? Sync: ngay trước mặt, trong response. Async: âm thầm phía sau — backlog, DLQ, lag (Phần 13.3). Hệ async đòi giám sát chủ động gấp đôi.
Ai phải biết ai tồn tại? Gọi trực tiếp: caller biết callee. Work queue: producer biết việc, không biết worker. Event log: producer không biết ai nghe (12.7). Hướng của sự phụ thuộc quyết định hệ thống tiến hóa dễ hay khó.

Quy tắc rút gọn xuyên suốt: command cần kết quả → sync (REST/gRPC); việc cần làm → work queue (RabbitMQ); sự thật đã xảy ra → log (Kafka). Ba công cụ, ba việc — dùng chéo là nguồn anti-pattern.

5.7. So sánh & khung quyết định lựa chọn

Mon, 13 Jul 2026 09:20:00 +0700

Chương tổng hợp của Phần 5. Nếu sáu chương trước là sáu công cụ, chương này là bàn tay cầm chúng.

1. Bảng so sánh theo quyết định gốc

	PostgreSQL	MySQL	MongoDB	Redis	ClickHouse	Elasticsearch
Cấu trúc lưu	Heap + B-tree	Clustered B-tree	B-tree (WiredTiger)	RAM structures	Columnar MergeTree	Inverted index (Lucene)
Đơn vị nhất quán	Transaction đa hàng	Transaction đa hàng	Document	Lệnh đơn	Không (eventual)	Document, không transaction
Trục tối ưu	Đọc/ghi điểm + query linh hoạt	Đọc/ghi điểm theo PK	Đọc/ghi cả object	Ops/s + latency µs–ms	Scan + aggregate	Tìm liên quan + facet
Điểm mù cấu trúc	Scan tỷ hàng; ghi append cực lớn	Như PG + analytics yếu hơn	Query cắt ngang document	Dataset > RAM; query đa chiều	Point read/update	Update dày; đếm chính xác; transaction
Scale ghi	1 writer (shard = tự lo)	1 writer (Vitess đường sẵn)	Sharding tích hợp	Cluster tích hợp	Cụm phân tán tốt	Shard tích hợp
Vai trong kiến trúc	Nguồn sự thật	Nguồn sự thật	Nguồn sự thật (đúng domain)	Dẫn xuất/phù du	Dẫn xuất	Dẫn xuất
Chi phí vận hành thêm	Thấp (managed phổ cập)	Thấp	Trung bình	Thấp–trung bình	Trung bình–cao	Cao

Hàng “vai trong kiến trúc” là hàng quan trọng nhất: hai cột đầu giữ sự thật; bốn cột sau phục vụ tốc độ. Nhầm vai là nguồn của các tai nạn lớn nhất (Redis làm nguồn sự thật, ES làm primary store, ClickHouse làm OLTP).

5.6. Elasticsearch — index, không phải database

Mon, 13 Jul 2026 09:10:00 +0700

1. Problem Statement

User gõ “ao khoac nam mua dong gia re” và mong đợi: kết quả liên quan (không phải khớp chuỗi), chịu được thiếu dấu/sai chính tả, filter theo giá/size/thương hiệu, facet đếm sẵn từng nhóm, autocomplete — tất cả dưới 100ms trên hàng triệu sản phẩm. Không cấu trúc nào ở các chương trước làm được việc này: B-tree trả lời “bằng/trong khoảng”, columnar trả lời “tổng theo nhóm” — không cái nào trả lời “chứa khái niệm X, xếp theo độ liên quan”. LIKE '%áo khoác%' là quét toàn bảng và vẫn sai về nghiệp vụ (không xếp hạng, không xử lý dấu, không tách từ).

5.5. ClickHouse — cỗ máy quét tỷ hàng

Mon, 13 Jul 2026 09:00:00 +0700

1. Problem Statement

Nhớ lại bảng ước lượng của chương 1.4: dữ liệu nghiệp vụ của VietShop là 4.4GB/năm — còn log/event là 11TB/năm. Đây là quy luật chung: dữ liệu hành vi (event, click, log, metric, telemetry) lớn hơn dữ liệu nghiệp vụ 2–3 bậc độ lớn, và câu hỏi đặt lên nó luôn có dạng: “tổng/đếm/trung bình của X, nhóm theo Y, trong khoảng thời gian Z” — quét triệu tới tỷ hàng, trả về vài trăm hàng kết quả. Chạy loại query này trên PostgreSQL là xem nó bò hàng chục phút và giết luôn OLTP đang chạy cạnh (12.8 — vấn đề mở màn của CQRS). ClickHouse được thiết kế cho đúng một việc này.

5.4. Redis — cấu trúc dữ liệu trong RAM

Mon, 13 Jul 2026 08:50:00 +0700

1. Problem Statement

Có một lớp dữ liệu mà disk-based DB nào cũng phục vụ được nhưng đều phục vụ đắt: truy cập cực dày (chục nghìn–triệu ops/s), latency yêu cầu sub-ms, vòng đời ngắn hoặc dựng lại được — cache, session, counter, rate limit, bảng xếp hạng, khóa tạm, hàng đợi nhẹ. Dùng PostgreSQL cho việc này là thuê container chở thư tay. Redis tồn tại để phục vụ đúng lớp này: cấu trúc dữ liệu quen thuộc (map, list, set, sorted set) sống trong RAM, thao tác atomic, latency ~0.1–1ms.

5.3. MongoDB — khi dữ liệu thật sự là document

Mon, 13 Jul 2026 08:40:00 +0700

1. Problem Statement

Một số dữ liệu chống lại việc trải phẳng thành bảng: catalog sản phẩm nơi mỗi ngành hàng một bộ thuộc tính (điện thoại có RAM/chip, áo có size/màu, sách có ISBN/tác giả), hồ sơ người dùng với cấu trúc lồng nhau nhiều tầng, payload sự kiện từ trăm nguồn khác nhau. Ép chúng vào quan hệ cho ra một trong hai thứ xấu: bảng 300 cột toàn NULL, hoặc EAV (entity-attribute-value — query 5 tầng join để dựng lại một object). MongoDB đặt cược vào mô hình khác: đơn vị lưu trữ = document (BSON) — object lồng nhau được lưu, đọc, ghi như một khối.

5.2. MySQL — người anh em song sinh khác tính cách

Mon, 13 Jul 2026 08:30:00 +0700

1. Problem Statement

Cùng bài toán với PostgreSQL: nguồn sự thật ACID cho dữ liệu nghiệp vụ. Câu hỏi thực tế của chương này không phải “MySQL là gì” mà là: hai RDBMS hàng đầu khác nhau ở đâu về bản chất, và khi nào sự khác biệt đó nghiêng cán cân? Đa số bài so sánh trên mạng liệt kê tính năng; chương này so sánh quyết định thiết kế gốc — vì tính năng đổi theo phiên bản, quyết định gốc thì không.

5.1. PostgreSQL — mặc định đúng cho dữ liệu nghiệp vụ

Mon, 13 Jul 2026 08:20:00 +0700

1. Problem Statement

Mọi hệ thống cần một nơi lưu sự thật nghiệp vụ: đơn hàng, tài khoản, số dư — dữ liệu mà nếu sai hoặc mất thì không xin lỗi được. Nơi đó phải: không mất dữ liệu đã xác nhận (durability), không cho hai thao tác giẫm nhau tạo trạng thái vô lý (isolation), giữ ràng buộc nghiệp vụ (constraint), và trả lời được các câu hỏi chưa biết trước (query linh hoạt). PostgreSQL là câu trả lời mặc định của ngành cho bài toán này — chương này giải thích vì sao, và quan trọng hơn: giới hạn của nó nằm ở đâu.

Phần 5 — Data Layer

Mon, 13 Jul 2026 08:10:00 +0700

Chủ đề: PostgreSQL, MySQL, MongoDB, Redis, ClickHouse, Elasticsearch — và quan trọng nhất: khi nào chọn cái gì.

Luận điểm trung tâm của phần này

Không có database “tốt nhất” — chỉ có database có mô hình lưu trữ và truy cập khớp với workload. Mọi khác biệt giữa các hệ quy về vài quyết định gốc mà mỗi engine đã chọn thay bạn từ ngày nó được thiết kế:

4.4. Clock Synchronization, Network Partition & Split Brain

Mon, 13 Jul 2026 08:00:00 +0700

1. Problem Statement

Ba “sự thật khó chịu” của hệ phân tán mà mọi thiết kế phải đối mặt:

Không có đồng hồ chung. Mỗi máy một đồng hồ, và chúng lệch nhau.
Mạng sẽ đứt — theo những cách kỳ quặc hơn bạn tưởng (đứt một chiều, đứt chập chờn, chậm-như-đứt).
Hệ quả của (1) + (2): split brain — hai phần của hệ thống cùng tin rằng mình là “chính”, cùng nhận ghi, và dữ liệu phân kỳ.

Chương này nối các nguyên lý ở 4.1–4.3 với các sự cố thực tế nhất của Phần 13.

4.3. Consensus, Quorum & Leader Election

Mon, 13 Jul 2026 07:50:00 +0700

1. Problem Statement

Một cụm nhiều node phải trả lời được những câu hỏi nghe rất tầm thường:

Ai là leader hiện tại?
Cấu hình hiện hành là bản nào?
Ghi này đã “chính thức” chưa (commit hay chưa)?

Điều phản trực giác: trong hệ phân tán, các câu hỏi này khó một cách nền tảng. Node không phân biệt được “node kia chết” với “mạng chậm” với “node kia đang GC pause”. Không có đồng hồ chung đáng tin. Message có thể đến trễ, đến hai lần, hoặc không đến. Consensus là bài toán làm cho N node đồng ý về một giá trị trong điều kiện đó — và nó là nền móng dưới mọi hệ thống phân tán nghiêm túc: failover tự động, distributed lock, config quản lý tập trung, Kafka controller, Kubernetes control plane.

4.2. Replication & Consistency Models

Mon, 13 Jul 2026 07:40:00 +0700

1. Problem Statement

Replication — giữ nhiều bản sao của cùng một dữ liệu trên nhiều node — tồn tại vì ba lý do, và chỉ ba:

Availability/Durability: máy chết, disk hỏng; bản sao thứ hai là thứ duy nhất đứng giữa bạn và mất dữ liệu.
Read scalability: một node có trần đọc; N bản sao nhân trần đọc lên ~N lần.
Latency theo địa lý: đặt bản sao gần user để đọc nhanh.

Nhưng khoảnh khắc tồn tại bản sao thứ hai, một câu hỏi không thể né sinh ra: hai bản sao có giống nhau không, vào lúc nào? Toàn bộ lý thuyết consistency models là các câu trả lời khác nhau cho câu hỏi này — mỗi câu trả lời một mức giá.

4.1. CAP Theorem & PACELC

Mon, 13 Jul 2026 07:30:00 +0700

1. Problem Statement

Khoảnh khắc hệ thống chuyển từ 1 node sang N node — vì cần chịu tải cao hơn hoặc sống sót khi 1 máy chết — nó bước vào lãnh thổ của Distributed Systems, nơi có những giới hạn toán học, không phải giới hạn kỹ thuật. Không framework nào, không cloud provider nào vượt qua được chúng. CAP và PACELC là hai giới hạn nền tảng nhất: chúng nói rằng một số tổ hợp thuộc tính mà bạn muốn là bất khả thi, và việc của Architect là chọn hy sinh cái gì.

3.3. Active-Active vs Active-Passive — hai triết lý redundancy

Mon, 13 Jul 2026 07:20:00 +0700

1. Problem Statement

Đã quyết có bản dự phòng (3.1) — câu hỏi kế: bản dự phòng làm gì trong lúc chờ? Ngồi im (passive) hay cùng phục vụ (active)? Nghe như chi tiết triển khai — thực chất là ngã ba triết lý với hệ quả lan đến tận mô hình dữ liệu: passive đơn giản nhưng đặt cược vào khoảnh khắc chuyển đổi chưa từng diễn ra thật; active-active dùng được tài nguyên và “failover liên tục từng giây” nhưng — với tầng có state — mở cánh cửa xung đột ghi mà 4.2 §2.2 đã cảnh báo.

3.2. Backup & Recovery — lớp phòng thủ cuối cùng

Mon, 13 Jul 2026 07:10:00 +0700

1. Problem Statement

Replication chống được máy hỏng — nhưng trung thành nhân bản mọi thảm họa logic trong mili-giây: DELETE nhầm, migration hỏng dữ liệu, ransomware mã hóa, bug ghi rác — replica có ngay bản sao hoàn hảo của sai lầm (3.README §3). Backup là lớp duy nhất chống được loại chết này: bản sao tách rời theo thời gian và theo quyền truy cập. Và câu hỏi thật của backup chưa bao giờ là “có backup không” — mà là: restore được không, trong bao lâu, mất bao nhiêu, và đã thử chưa? Backup chưa từng restore thử là một niềm tin, không phải một năng lực.

3.1. High Availability & Failover — giải phẫu quá trình chuyển đổi

Mon, 13 Jul 2026 07:00:00 +0700

1. Problem Statement

Business nói: “hệ thống không được chết quá 43 phút mỗi tháng” (99.9% — 1.2). Máy sẽ chết, disk sẽ hỏng, AZ sẽ sập — vậy con số kia chỉ đạt được bằng một cách: khi một bộ phận chết, bộ phận dự phòng tiếp quản nhanh hơn ngưỡng người dùng bỏ đi. HA = redundancy (có dự phòng) × failover (chuyển đổi đúng và nhanh). Vế thứ hai khó hơn vế thứ nhất một bậc — và là nơi các sự cố HA thực tế xảy ra: hệ thống có đủ bản sao nhưng chuyển đổi sai còn tệ hơn không có bản sao (13.4 — split brain).

Phần 3 — Availability & Reliability

Mon, 13 Jul 2026 06:50:00 +0700

Chủ đề: High Availability, Failover, Replication (phối hợp), Backup, Disaster Recovery, Active-Active, Active-Passive.

Luận điểm trung tâm của phần này

Availability là kết quả của thiết kế cho sự cố, không phải của phần cứng tốt: mọi thành phần sẽ hỏng — câu hỏi duy nhất là hệ thống phản ứng thế nào khi điều đó xảy ra. Ba mệnh đề nền:

Mỗi “số 9” thêm đắt ~10 lần (1.2); và từ 99.99% trở lên, con người không kịp phản ứng — mọi failover phải tự động, kéo theo toàn bộ Phần 4. Ranh giới 3 số 9 / 4 số 9 là ranh giới kiến trúc, không phải ranh giới nỗ lực.
Redundancy chỉ là tiềm năng — failover mới là năng lực. N bản sao không cứu được ai nếu quá trình chuyển đổi sai (13.4 — split brain); và failover chưa từng diễn tập là failover trên giấy.
Replication ≠ Backup ≠ DR — ba lớp chống ba loại chết khác nhau (máy hỏng / dữ liệu hỏng / tổ chức không biết làm gì); cần cả ba, thiếu lớp nào lộ lớp đó đúng ngày xấu trời (12.10).

Mục lục

Bản đồ chủ đề trong toàn tài liệu

Mảnh	Ở đâu
Định nghĩa và chi phí các “số 9”, error budget	1.2
Replication chi tiết (sync/async, mô hình)	4.2
Quorum, leader election, fencing — bộ máy failover an toàn	4.3, 4.4
DR như năng lực tổ chức: RPO/RTO, 4 lớp, diễn tập	12.10
Multi-region	12.9
Các sự cố ăn mòn availability	Phần 13 toàn bộ

Phần này là mô-đun nối: đi sâu vào những gì các phần trên chưa phủ — giải phẫu failover, kỹ nghệ backup, và lựa chọn active-active/passive như một khung quyết định.

2.3. Auto Scaling — co giãn theo tải mà không thức đêm

Mon, 13 Jul 2026 06:40:00 +0700

1. Problem Statement

Tải không phẳng: ngày gấp 3 đêm, tối gấp 2 trưa, flash sale gấp 10 ngày thường (1.4). Provision cho đỉnh = trả tiền công suất ngủ 80% thời gian; provision cho trung bình = gãy latency mỗi tối (1.3 — hockey stick). Auto scaling hứa điều thứ ba: công suất bám theo tải. Lời hứa có điều kiện — và các điều kiện đó (stateless, khởi động nhanh, metric đúng, biết giới hạn tốc độ của chính nó) là nội dung thật của chương này.

2.2. Load Balancer — người gác cổng của scale-out

Mon, 13 Jul 2026 06:30:00 +0700

1. Problem Statement

Có N instance giống nhau (2.1); cần một thứ đứng trước để: chia request đều theo tải thật (không phải đều theo số đếm), phát hiện máy chết và loại nó trước khi user cảm nhận, cho phép thêm/bớt máy giữa dòng traffic, và tự nó không trở thành SPOF mới. Bốn yêu cầu nghe hiển nhiên — mỗi cái là một bài thiết kế có chiều sâu, và LB cấu hình mặc định thường trượt cả bốn ở những cách kín đáo.

2.1. Vertical vs Horizontal Scaling — và bài toán state

Mon, 13 Jul 2026 06:20:00 +0700

1. Problem Statement

Hệ thống chạm trần một máy: CPU bão hòa giờ peak, latency gãy (1.3 — hockey stick). Hai con đường: máy to hơn (vertical/scale-up) hay nhiều máy hơn (horizontal/scale-out)? Câu hỏi nghe như so sánh giá tiền — thực chất là so sánh hai triết lý kiến trúc, và con đường thứ hai có một điều kiện tiên quyết bị đánh giá thấp một cách hệ thống: state phải dọn nhà trước.

Phần 2 — Scalability

Mon, 13 Jul 2026 06:10:00 +0700

Chủ đề: Vertical Scaling, Horizontal Scaling, Stateless vs Stateful, Sticky Session, Load Balancer, Auto Scaling.

Luận điểm trung tâm của phần này

Scalability không phải “chịu được nhiều tải” — mà là chi phí tăng tuyến tính (hoặc chậm hơn) theo tải, không cần thiết kế lại (1.1). Hệ scale kém không phải hệ chậm — là hệ mà tải tăng 2× thì chi phí tăng 10× hoặc phải viết lại.

1.5. Bottleneck Analysis

Mon, 13 Jul 2026 06:00:00 +0700

1. Problem Statement

Hệ thống chậm/quá tải, và team đứng trước cám dỗ lớn nhất của nghề: tối ưu thứ dễ thấy thay vì thứ đang nghẽn. Thêm cache khi vấn đề là lock contention. Thêm server khi vấn đề là connection pool. Rewrite sang Go khi vấn đề là một câu query thiếu index.

Bottleneck analysis là kỹ năng tìm đúng chỗ nghẽn trước khi hành động. Nó quan trọng vì một định luật không khoan nhượng: tối ưu bất cứ thứ gì không phải bottleneck đều không cải thiện hệ thống (Theory of Constraints). Tăng gấp đôi tốc độ một thành phần đang rảnh 60% thời gian → thay đổi tổng thể: ~0.

1.4. Scale Estimation & Capacity Planning

Mon, 13 Jul 2026 05:50:00 +0700

1. Problem Statement

Hai câu hỏi mà mọi thiết kế phải trả lời bằng con số, không phải bằng tính từ:

Scale Estimation: hệ thống phải chịu bao nhiêu — user, request, dữ liệu?
Capacity Planning: cần bao nhiêu tài nguyên — máy, RAM, disk, băng thông — để chịu mức đó, hôm nay và 12 tháng tới?

Không có hai con số này, mọi tranh luận kiến trúc (“có cần sharding không?”, “Postgres chịu nổi không?”) là tranh luận cảm tính. Với con số, phần lớn tranh luận tự biến mất — vì đáp án trở nên hiển nhiên.

1.3. Throughput & Latency

Mon, 13 Jul 2026 05:40:00 +0700

1. Problem Statement

“Hệ thống chậm” là câu phàn nàn phổ biến nhất và mơ hồ nhất trong ngành. Chậm vì mỗi request mất lâu (latency)? Hay vì hệ thống không nuốt nổi số lượng request (throughput bão hòa → queue → chờ)? Hai bệnh khác nhau, thuốc khác nhau, nhưng triệu chứng bề mặt giống hệt nhau: “user thấy lâu”.

Hiểu sâu quan hệ giữa latency, throughput, concurrency và utilization là kỹ năng chẩn đoán nền tảng — thiếu nó, mọi nỗ lực tối ưu là đoán mò.

1.2. SLA, SLO, SLI

Mon, 13 Jul 2026 05:30:00 +0700

1. Problem Statement

“Hệ thống có ổn định không?” là câu hỏi không trả lời được nếu không có định nghĩa đo được về “ổn định”. Team vận hành nói uptime 99.98%, nhưng khách hàng phàn nàn liên tục — vì uptime đo bằng ping đến server, còn khách hàng đo bằng “đặt hàng có thành công không”. Hai thước đo khác nhau về cùng một hệ thống.

SLI/SLO/SLA là bộ công cụ biến “độ tin cậy” từ cảm giác thành hợp đồng đo được — giữa hệ thống với khách hàng, và giữa team engineering với chính mình.

1.1. Functional & Non-functional Requirements

Mon, 13 Jul 2026 05:20:00 +0700

1. Problem Statement

Mọi thất bại kiến trúc lớn đều bắt nguồn từ một trong hai lỗi:

Thiết kế cho yêu cầu không tồn tại — xây hệ thống chịu 100K RPS cho sản phẩm có 200 user.
Bỏ sót yêu cầu ngầm — không ai nói “hệ thống thanh toán không được mất tiền khi crash”, vì ai cũng nghĩ điều đó hiển nhiên; cho đến khi nó xảy ra.

Requirements engineering trong system design không phải thủ tục giấy tờ. Nó là công cụ định giá: mỗi yêu cầu có một chi phí kiến trúc, và việc của Architect là làm chi phí đó hiện hình trước khi viết dòng code đầu tiên.

00. Tư Duy Thiết Kế Hệ Thống

Mon, 13 Jul 2026 05:10:00 +0700

Chương này là nền móng của toàn bộ tài liệu. Nếu bạn chỉ đọc một chương, hãy đọc chương này.

1. Vấn đề của cách học System Design phổ biến

Phần lớn tài liệu System Design trên thị trường dạy theo kiểu: “Design Twitter thì dùng fan-out, design Uber thì dùng geohash, design URL shortener thì dùng base62”. Người học ghi nhớ ánh xạ từ đề bài sang lời giải, không hiểu vì sao lời giải tồn tại.

System Design — Mục Lục & Cách Đọc Tài Liệu

Mon, 13 Jul 2026 05:00:00 +0700

Tài liệu chuyên sâu về System Design dành cho Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect và Software Architect.

Mục tiêu: xây dựng tư duy thiết kế hệ thống — không phải bộ sưu tập lời giải phỏng vấn.

Triết lý của tài liệu

Mọi quyết định kiến trúc trong tài liệu này đều đi theo chuỗi tư duy:

Business Requirement
↓
Functional Requirement
↓
Non-functional Requirement
↓
Scale Estimation
↓
Constraint
↓
Bottleneck
↓
Architecture Pattern
↓
Distributed Systems
↓
Trade-off
↓
Production
↓
Evolution

Mọi kết luận kỹ thuật phải trả lời được 5 câu hỏi: