System-Design

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

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

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

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

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

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

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

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

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

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

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

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

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 3.1. High Availability & Failover — giải phẫu quá trình chuyển đổi 3.2. Backup & Recovery — lớp phòng thủ cuối cùng 3.3. Active-Active vs Active-Passive — hai triết lý redundancy 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. ...

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

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

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

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

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

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 ↓ EvolutionMọi kết luận kỹ thuật phải trả lời được 5 câu hỏi: ...

Chào mọi người, gần đây khi mình chuyển sang công việc mới với một ngôn ngữ lập trình khác, mình có cơ hội tham gia thiết kế một hệ thống rule engine để đáp ứng các yêu cầu business của công ty. Trong quá trình tìm hiểu và research, mình muốn ghi lại những kiến thức đã học được, đồng thời chia sẻ lại theo một scope phổ biến hơn để phù hợp với nhiều mô hình business hiện nay. Bài viết này vừa để mình hệ thống hóa kiến thức, vừa hy vọng giúp ích cho những bạn đang quan tâm đến rule engine. ...