Level 3–5. Chương 5 hứa: “crash không mất gì, WAL dựng lại được”. Chương này trả nghĩa vụ chứng minh — và mở rộng cùng cơ chế đó thành PITR và replication: ba tính năng, một nền tảng duy nhất là WAL replay. 1. Problem Statement Crash recovery: sau mất điện, dựng lại trạng thái đã commit — tự động, không thao tác tay, thời gian đoán được. Backup/PITR: “khôi phục về 14:59, ngay trước câu DELETE nhầm lúc 15:00” — backup định kỳ thuần túy không làm nổi. Replication: bản sao nóng, trễ mili giây, đọc được — và failover khi primary chết. Cả ba là cùng một bài toán: tái tạo trạng thái từ (một ảnh chụp cũ) + (dòng WAL). Ai kiểm soát điểm dừng replay, người đó có tính năng tương ứng: dừng ở cuối WAL = crash recovery; dừng ở timestamp = PITR; không bao giờ dừng = replica. ...

Level 3–5. MVCC vay nợ: mỗi UPDATE/DELETE để lại rác, mỗi transaction đốt một XID hữu hạn. VACUUM là bộ máy trả nợ. Vận hành PostgreSQL nghiêm túc = vận hành VACUUM nghiêm túc. Chương này là chương “đáng tiền” nhất với người trực production. 1. Problem Statement — ba món nợ của MVCC Dead tuple: version cũ không còn snapshot nào cần (Chương 6). Không dọn → bảng/index phình, cache loãng, scan chậm. Không gian XID hữu hạn: XID 32 bit so sánh vòng tròn. Tuple mang xmin quá già (cách hiện tại >2³¹) sẽ bị phép so sánh hiểu ngược thành “tương lai” → dữ liệu committed biến mất. Phải “đóng băng” (freeze) tuple già trước khi điều đó xảy ra. Thống kê & Visibility Map lạc hậu: planner cần ANALYZE; index-only scan cần VM được cập nhật. VACUUM giải cả ba. Nếu bỏ VACUUM? — không phải “chậm dần” mà là dừng hẳn: đầy disk vì bloat, rồi trước cả đó, cluster tự khóa ghi để chống wraparound. Không có lựa chọn “không vacuum”, chỉ có “vacuum có kiểm soát” hoặc “vacuum lúc 3h sáng theo lệnh của PostgreSQL”. ...

Level 4. Index là cấu trúc dữ liệu trên disk — nghĩa là mọi thiết kế của nó bị chi phối bởi page 8KB, WAL, MVCC và concurrency. Chương này mở nắp từng loại. 1. Problem Statement Heap không có thứ tự (Chương 3): tìm WHERE email='x@y.vn' = đọc toàn bộ bảng, O(N) page. Bảng 100GB → ~13 giây chỉ riêng I/O tuần tự, mỗi query. Cần cấu trúc phụ ánh xạ giá trị → ctid với chi phí tra cứu ~O(log N) tính bằng số page (không phải số phần tử — mỗi page là một lần I/O tiềm năng). ...

Level 4. SQL là ngôn ngữ khai báo: bạn nói cần gì, không nói làm thế nào. Toàn bộ chương này là câu chuyện PostgreSQL biến “cần gì” thành “làm thế nào” — và tại sao đôi khi nó chọn sai. 1. Problem Statement SELECT c.name, sum(o.amount) FROM customers c JOIN orders o ON o.customer_id = c.id WHERE c.region = 'APAC' AND o.created_at > now() - interval '30 days' GROUP BY c.name; Câu này có thể thực thi theo hàng nghìn cách: quét bảng nào trước, dùng index nào, join bằng thuật toán nào, group bằng hash hay sort. Chênh lệch giữa plan tốt nhất và tệ nhất trên dữ liệu lớn: 10⁴–10⁶ lần. Không tầng nào khác của database tạo ra chênh lệch hiệu năng lớn như planner. ...

Level 3. MVCC loại bỏ xung đột reader–writer. Phần còn lại — writer–writer, DDL, và bảo vệ cấu trúc trong bộ nhớ — thuộc về ba tầng lock của PostgreSQL. Đa số sự cố “database treo” trong production là sự cố lock, không phải sự cố I/O. 1. Problem Statement Ba lớp bài toán tranh chấp khác nhau về bản chất và thang thời gian: Micro (nanô giây): hai CPU cùng sửa một biến trong shared memory (refcount của buffer). Cần loại trừ trong vài chục chu kỳ CPU. Meso (micro giây): một backend sửa nội dung page trong khi backend khác đọc. Cần read/write lock ngắn. Macro (mili giây → giờ): hai transaction cùng UPDATE một row; ALTER TABLE trong khi query đang chạy. Cần lock theo ngữ nghĩa transaction: có hàng đợi, có phát hiện deadlock, tự nhả khi commit. Một cơ chế duy nhất không phục vụ nổi cả ba (lock có hàng đợi + deadlock detection quá đắt cho việc tăng một biến đếm). PostgreSQL xây ba tầng: ...

Level 3. MVCC là quyết định thiết kế trung tâm của PostgreSQL. Hiểu nó là hiểu được: tại sao reader không block writer, tại sao có dead tuple, tại sao có VACUUM, tại sao “idle in transaction” là kẻ giết hệ thống thầm lặng. 1. Problem Statement 1.000 transaction đồng thời trên cùng bảng. Yêu cầu Isolation: mỗi transaction thấy database như một ảnh chụp nhất quán, không thấy thay đổi dở dang của người khác. ...

Level 3. WAL là phát minh quan trọng nhất của ngành database (ARIES, 1992). Nó là lý do PostgreSQL dám giữ dirty page trong RAM, là nền của recovery, replication, PITR — và là nguồn của một nửa số sự cố production về disk. 1. Problem Statement Chương 1 xác lập hai sự thật vật lý mâu thuẫn nhau: Durability đòi hỏi fsync trước khi báo commit — mà fsync đắt (~0.1–1ms NVMe, ~10ms HDD). Thay đổi của một transaction rải rác trên nhiều page (heap, nhiều index, toast) — fsync tất cả các page đó mỗi commit = nhiều random write + nhiều fsync → vài chục ms mỗi commit → throughput chết. Thêm bài toán thứ ba: page 8KB > sector atomic 4KB → crash giữa lúc ghi page tạo torn page — nửa mới nửa cũ, checksum sai, không dùng được. ...

Level 2. Disk chậm hơn RAM ~1000 lần. Buffer Manager là tầng quyết định PostgreSQL chạy ở tốc độ RAM hay tốc độ disk — tức là quyết định 90% cảm nhận hiệu năng. 1. Problem Statement Mỗi thao tác đọc/ghi tuple đều cần page 8KB tương ứng. Nếu mỗi lần đều read()/write() xuống disk: một query đọc 1 triệu tuple rải trên 100k page × ~100µs/lần đọc NVMe = 10 giây thuần I/O — trong khi từ RAM mất ~50ms. ...

Level 2. Đây là chương nền tảng nhất của bộ tài liệu. Hiểu từng byte của heap page là hiểu được một nửa PostgreSQL: MVCC, VACUUM, HOT, bloat, index — tất cả đều quy về đây. 1. Problem Statement Bảng orders 200GB phải nằm trên disk sao cho: Tìm một order theo con trỏ mất đúng 1 lần đọc disk. Thêm order mới không phải dịch chuyển dữ liệu cũ. Nhiều version của một row (MVCC) cùng tồn tại được. Crash giữa chừng không phá cấu trúc. Cột note dài 1MB không làm hỏng hiệu quả của các cột 8 byte bên cạnh. Nếu tổ chức sai tầng này: mọi thao tác đọc thành O(n), UPDATE phải rewrite file, crash để lại file rác. Toàn bộ chương này là câu trả lời của PostgreSQL cho bài toán đó. ...

Level 1–2. PostgreSQL là một “hệ điều hành thu nhỏ”: có process quản lý, có bộ nhớ chia sẻ, có scheduler nền, có cơ chế phục hồi. Chương này vẽ bản đồ toàn bộ hệ thống đó. 1. Problem Statement Một database server phải đồng thời: phục vụ hàng trăm connection, ghi dữ liệu nền, dọn rác, đồng bộ replica, thu thập thống kê — mà một thành phần chết không được kéo sập dữ liệu. Bài toán: tổ chức các đơn vị thực thi (process/thread) và bộ nhớ chung như thế nào để vừa cô lập lỗi, vừa chia sẻ trạng thái hiệu quả? ...

Level 1. Trước khi nói về PostgreSQL, phải trả lời câu hỏi gốc: tại sao phần mềm quản lý dữ liệu lại khó đến mức cần một engine hàng triệu dòng code? 1. Problem Statement Mọi hệ thống phần mềm đều quy về một bài toán: nhận dữ liệu, lưu dữ liệu, trả lại dữ liệu đúng. Một hệ thống thanh toán nhận lệnh chuyển 500.000đ từ tài khoản A sang B. Yêu cầu nghe đơn giản: ...

Bộ tài liệu chuyên sâu về cách PostgreSQL hoạt động bên dưới lớp SQL và Storage, viết cho Backend Engineer, Database Engineer và Software Architect. Tài liệu này KHÔNG phải là gì Đây không phải tài liệu dạy SQL. Không có CREATE TABLE ở chương mở đầu. Không giải thích cú pháp. Đây là tài liệu giúp bạn hiểu PostgreSQL như một hệ điều hành thu nhỏ dành cho dữ liệu: cách nó tổ chức bộ nhớ, quản lý page, lưu tuple, điều phối transaction, ghi WAL, phục hồi sau sự cố, tối ưu truy vấn, và phối hợp với OS để đạt hiệu năng và độ tin cậy. ...

Phần 4 | Chương trước: So sánh khách quan | Về mục lục Mỗi chương factor đã có mục “khi nào không áp dụng” riêng. Chương cuối này tổng hợp chúng thành một khung quyết định — và khép lại tài liệu bằng những điều đáng mang theo nhất. 1. Nguyên tắc gốc để suy luận ngoại lệ Toàn bộ 12-Factor suy ra từ một tiền đề (chương 2): hạ tầng tạm bợ, được tự động hóa, app chạy nhiều bản sao. Vậy quy tắc suy ngoại lệ rất gọn: ...

Phần 4 | Chương trước: Case study | Chương sau: Khi nào KHÔNG nên áp dụng Các chương trước đã rải trade-off theo từng chủ đề. Chương này gom chúng thành các bảng so sánh trực diện — công cụ cho các buổi tranh luận kiến trúc, nơi câu hỏi không phải “cái nào hay hơn” mà là “cái nào đúng cho ràng buộc của chúng ta”. 1. Traditional Deployment vs 12-Factor App Tiêu chí Traditional (VM + deploy tay) 12-Factor trên nền tảng tự động Chi phí khởi đầu Rất thấp — một VM, một binary Trung bình — pipeline, registry, nền tảng Tần suất release an toàn Tuần–quý Ngày–giờ Rollback Cầu may Một lệnh, một phút Scale Dọc, có trần, chậm Ngang, theo phút, hai chiều Phục hồi sự cố máy Giờ–ngày (snowflake) Tự động (cattle) Kỹ năng đòi hỏi Sysadmin cơ bản Container, CI/CD, orchestration Điểm hòa vốn Hệ nhỏ, ít thay đổi, 1–2 người Nhiều release, nhiều instance, nhiều người Điểm giống thường bị bỏ qua: cả hai đều cần kỷ luật version control, backup, giám sát — 12-Factor không thay thế những cái đó, nó xây trên chúng. Khi nào chọn traditional: đã phân tích xuyên suốt (chương 1, 26) — hệ nhỏ ổn định, một máy đủ, đội mỏng. Lưu ý chiều ngược: chọn traditional rồi vẫn giữ config-tách-code, log-stdout, Git — 4 factor rẻ nhất không có lý do bỏ ở bất kỳ mô hình nào. ...

Phần 4 – Thực chiến | Chương trước: Chủ đề Principal | Chương sau: So sánh khách quan Chương này ghép mọi mảnh của 24 chương trước thành một hệ thống hoàn chỉnh: dịch vụ đặt hàng orderly — REST API nhận đơn hàng, lưu PostgreSQL, cache Redis, phát sự kiện Kafka cho worker xử lý. Cấu trúc chương: hiện trạng “trước refactor” → kiến trúc đích → code đầy đủ → hạ tầng → pipeline → nhật ký refactor từng bước với lý do. ...

Phần 4 – Principal | Chương trước: Observability | Chương sau: Case study REST API Đến đây, các nguyên lý đã đầy đủ. Chương này trả lời câu hỏi của tầng principal: khi hệ thống và tổ chức lớn lên 10–100 lần, các nguyên lý đó biến hình thế nào? Mỗi mục đi nhanh nhưng đủ khung quyết định. 1. Multi-region Deployment Bài toán. Một region là một miền sự cố (AWS us-east-1 đã nhiều lần chứng minh); latency vật lý (Việt Nam → Singapore ~30–40ms, → US ~200ms); và yêu cầu pháp lý về nơi lưu dữ liệu (data residency). ...

Phần 3 – Engineering | Chương trước: CI/CD | Chương sau: Chủ đề Principal Factor 11 chỉ nói về log — vì năm 2011 hệ thống điển hình là một app monolith vài instance. Hệ phân tán hiện đại cần nhiều hơn: observability — khả năng đặt câu hỏi chưa nghĩ trước về trạng thái hệ thống từ dữ liệu nó phát ra. Đây là “factor 13” không chính thức mà mọi bản cập nhật 12-Factor đều bổ sung. ...

Phần 3 – Engineering | Chương trước: Kubernetes | Chương sau: Observability Factor 5 định nghĩa ba giai đoạn build–release–run; chương này xây cỗ máy thi hành chúng: pipeline CI/CD hoàn chỉnh với GitHub Actions, và mô hình GitOps cho phần deploy. 1. Bản chất: CI/CD là gì — tách bạch hai khái niệm CI (Continuous Integration): mọi thay đổi được tích hợp vào trunk thường xuyên, và mỗi lần tích hợp được kiểm chứng tự động (build + test). CI là về niềm tin vào trạng thái của trunk: trunk luôn ở trạng thái ship được. CD có hai nghĩa cần phân biệt: Continuous Delivery — mọi commit qua CI đều sẵn sàng deploy (artifact + quy trình tự động, người bấm nút); Continuous Deployment — bỏ luôn nút bấm, mọi commit xanh tự lên production. Đa số tổ chức trưởng thành dừng ở Delivery cho production và Deployment cho staging — đó là lựa chọn quản trị rủi ro, không phải mức độ “tiến hóa”. Điểm nối với 12-Factor: pipeline chính là ranh giới cưỡng chế của các factor — codebase (chỉ build từ Git), dependencies (verify trong CI), build/release/run (mỗi stage một job), parity (cùng artifact đi xuyên môi trường). Kỷ luật con người thất bại theo thời gian; kỷ luật pipeline thì không. ...

Phần 3 – Engineering | Chương trước: Docker | Chương sau: CI/CD Nếu 12-Factor là hợp đồng phía ứng dụng thì Kubernetes là bên thi hành phía nền tảng. Chương này đọc Kubernetes qua lăng kính đó: mỗi khái niệm K8s là câu trả lời cho một factor — và một app không theo 12-Factor sẽ vô hiệu hóa chính những khả năng bạn trả tiền để có. 1. Mô hình tư duy cốt lõi: declarative + reconciliation Toàn bộ Kubernetes đứng trên một vòng lặp: ...

Phần 3 – Engineering | Chương trước: Golang Patterns | Chương sau: Kubernetes Container không phải một factor — nó là công nghệ hiện thực hóa nhiều factor cùng lúc: F2 (isolate dependencies), F5 (build artifact bất biến), F10 (cùng image mọi môi trường), và là đơn vị của F6/F8/F9 (process/scale/dispose). Chương này đi từ bản chất container đến Dockerfile production tối ưu. 1. Bản chất: container là gì (và không phải là gì) Container không phải VM nhẹ. VM ảo hóa phần cứng (mỗi VM một kernel riêng); container ảo hóa hệ điều hành — mọi container trên một máy dùng chung kernel host, được cô lập bằng hai cơ chế Linux: ...

Phần 3 – Engineering | Chương trước: Admin Processes | Chương sau: Docker Phần 2 đã rải các mảnh code Go theo từng factor. Chương này hệ thống hóa chúng thành bộ pattern hoàn chỉnh của một service Go production-ready: cấu trúc, dependency injection, health check, signal handling, và một bộ khung main() chuẩn có thể tái sử dụng cho mọi service. 1. Cấu trúc project — kiến trúc phản chiếu các factor myapp/ ├── go.mod / go.sum # F2 ├── cmd/app/main.go # composition root — nơi DUY NHẤT wiring mọi thứ ├── internal/ │ ├── config/config.go # F3 — nơi DUY NHẤT đọc env │ ├── logging/logging.go # F11 — slog JSON ra stdout │ ├── server/ # F7, F9 — HTTP server, health, graceful shutdown │ │ ├── server.go │ │ └── middleware/ │ ├── service/ # business logic — KHÔNG import repository/postgres, │ │ └── order.go # chỉ import interface nó tự khai báo │ ├── repository/postgres/ # F4 — implementation của backing service │ ├── queue/ # F4, F8 — producer/consumer │ └── migrate/sql/ # F12 — migration embed └── deploy/ # Dockerfile, k8s/, composeNguyên tắc phụ thuộc: cmd → internal/{server,service,repository}; service chỉ biết interface; config không import gì của app. Vòng phụ thuộc là mùi thiết kế — Go từ chối compile là đồng minh của bạn. ...

“Run admin/management tasks as one-off processes” — Chạy tác vụ quản trị như các process một lần. Phần 2 – The Twelve Factors | Nhóm: Operable | Chương trước: Logs | Chương sau: Golang Patterns 1. Problem Statement Ngoài dòng traffic chính, hệ thống nào cũng có tác vụ quản trị: database migration, backfill dữ liệu, sửa dữ liệu hỏng một lần, chạy lại job fail, script thống kê, xóa dữ liệu hết hạn theo lịch. Câu hỏi của factor này: các tác vụ đó chạy ở đâu, bằng code nào, với môi trường nào? ...

“Treat logs as event streams” — Coi log là dòng sự kiện. Phần 2 – The Twelve Factors | Nhóm: Operable | Chương trước: Dev/Prod Parity | Chương sau: Admin Processes 1. Problem Statement Mô hình cũ: app ghi log vào file (/var/log/app/app.log), tự lo rotate, nén, xóa. Trên hạ tầng hiện đại, mô hình đó gãy ở mọi khớp: Filesystem là tạm bợ: container chết là file log chết theo — đúng lúc bạn cần log nhất (điều tra vì sao nó chết) thì log đã bay màu cùng nó. Nhiều instance: 30 pod = 30 file log trên 30 node — “grep file log” đòi hỏi biết pod nào xử lý request nào, điều bạn không thể biết trước. App phải biết quá nhiều: đường dẫn, quyền ghi, rotate policy, dung lượng — toàn tri thức về môi trường, vi phạm nguyên tắc environment coupling ngay từ chương 1. Tệ hơn: ghi vào filesystem phá readOnlyRootFilesystem, và disk đầy vì log là sự cố “tự bắn vào chân” kinh điển. Factor 11 tách đôi trách nhiệm bằng một hợp đồng tối giản: ...

“Keep development, staging, and production as similar as possible” — Giữ các môi trường giống nhau nhất có thể. Phần 2 – The Twelve Factors | Nhóm: Reproducible | Chương trước: Disposability | Chương sau: Logs 1. Problem Statement Câu nói ám ảnh nhất ngành vận hành: “Trên staging chạy mà!” Mọi tầng kiểm thử (unit test, integration test, staging, QA) đều dựa trên một giả định ngầm: môi trường kiểm thử dự đoán được môi trường thật. Mỗi khác biệt giữa hai môi trường đục một lỗ vào giả định đó — và bug sẽ chui đúng qua những lỗ ấy, xuất hiện chỉ trên production, nơi chi phí sửa cao nhất và công cụ debug nghèo nhất. ...

“Maximize robustness with fast startup and graceful shutdown” — Tối đa hóa độ bền vững bằng khởi động nhanh và tắt êm. Phần 2 – The Twelve Factors | Nhóm: Disposable & Scalable | Chương trước: Concurrency | Chương sau: Dev/Prod Parity 1. Problem Statement Chương 2 đã xác lập: trên hạ tầng hiện đại, process của bạn sẽ bị giết — thường xuyên, và phần lớn là có chủ đích. Hãy đếm các sự kiện giết process trong một tuần vận hành K8s bình thường: ...

“Scale out via the process model” — Scale bằng cách nhân bản process. Phần 2 – The Twelve Factors | Nhóm: Disposable & Scalable | Chương trước: Port Binding | Chương sau: Disposability 1. Problem Statement Câu hỏi: “Khi tải tăng, hệ thống lớn lên bằng cách nào?” Hai con đường: SCALE UP (dọc) SCALE OUT (ngang) ──────────────── ───────────────── Máy to hơn: thêm CPU/RAM Nhiều bản sao hơn của process + Không đổi kiến trúc + Không có trần (thêm máy là được) + Đơn giản + Chi tiết hóa: scale đúng phần cần − Có TRẦN vật lý + Kèm luôn HA (một bản chết còn bản khác) − Giá phi tuyến (máy 2x đắt >2x) − ĐÒI HỎI app đúng kiểu: stateless (F6), − Downtime khi nâng cấp port binding (F7), disposable (F9) − Một máy chết = chết hết − Phức tạp hơn: LB, orchestratorFactor 8 chọn scale out, và chỉ rõ đơn vị scale là process (ngày nay: container/pod — một process trong một container). Không có gì tự nhiên ở lựa chọn này — nó là hệ quả: đã stateless (F6) thì nhân bản là an toàn; đã bind port (F7) thì nhân bản là lắp thêm vào load balancer; và ngược lại, chọn scale out thì bắt buộc F6, F7. Các factor khóa lẫn nhau. ...

“Export services via port binding” — Xuất khẩu dịch vụ qua việc bind port. Phần 2 – The Twelve Factors | Nhóm: Disposable & Scalable | Chương trước: Processes | Chương sau: Concurrency 1. Problem Statement Factor này khó cảm nhận với dev Go — vì Go mặc định đã đúng. Để hiểu nó giải quyết gì, phải nhìn về mô hình mà nó phủ định: ứng dụng sống ký sinh trong một app server. ...

“Execute the app as one or more stateless processes” — Chạy ứng dụng như một hoặc nhiều process stateless. Phần 2 – The Twelve Factors | Nhóm: Disposable & Scalable | Chương trước: Build, Release, Run | Chương sau: Port Binding Đây là factor trung tâm của cả 12 — nếu chỉ được giữ một factor, hãy giữ factor này. Nền lý thuyết đã trình bày kỹ ở chương 4; chương này tập trung vào thực chiến: nhận diện state ẩn, refactor, và các tình huống xám. ...

“Strictly separate build and run stages” — Tách bạch nghiêm ngặt các giai đoạn build và run. Phần 2 – The Twelve Factors | Nhóm: Reproducible | Chương trước: Backing Services | Chương sau: Processes 1. Problem Statement Câu hỏi factor này trả lời: “Từ code đến process đang chạy, chuyện gì xảy ra — và có đảo ngược được không?” Trong thế giới chương 1, ba việc trộn làm một: build trên máy dev, copy lên server, sửa config tại chỗ, có khi sửa cả code tại chỗ. Hệ quả: ...

“Treat backing services as attached resources” — Coi mọi backing service là tài nguyên gắn kèm. Phần 2 – The Twelve Factors | Nhóm: Configurable | Chương trước: Config | Chương sau: Build, Release, Run 1. Problem Statement Backing service = bất kỳ dịch vụ nào app tiêu thụ qua mạng để hoạt động: database (PostgreSQL, MySQL), cache (Redis, Memcached), message broker (Kafka, RabbitMQ), object storage (S3, MinIO), SMTP, dịch vụ bên thứ ba (payment gateway, Maps API), và cả các service khác trong chính hệ thống của bạn. ...