System Design — Tư Duy Thiết Kế Hệ Thống

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”. ...

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 11.1. Authentication & Authorization — bạn là ai, bạn được làm gì 11.2. OAuth2, OIDC & JWT — ủy quyền và token trong hệ phân tán 11.3. Biên phòng thủ — API Gateway, Rate Limiting, WAF 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. ...

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. ...

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. ...

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. ...

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. ...

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). ...

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. ...

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. ...

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. ...

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”. ...

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). ...

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ẻ. ...

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. ...

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. ...

“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. ...

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. ...

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ề. ...

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). ...

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. ...

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. ...

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. ...

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. ...

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. ...

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. ...

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ó. ...

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. ...

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). ...

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ừ). ...

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. ...