Backend

Level 2 – Engineering · Yêu cầu: đã hoàn thành Level 1. 1. Problem Statement: câu chuyện lặp lại của mọi hệ thống Robert C. Martin công bố bài viết “The Clean Architecture” năm 2012, đúc kết từ hàng thập kỷ quan sát một vòng đời lặp đi lặp lại: Năm 1: team chọn framework hot nhất (Rails/Spring/Django — ngày nay có thể là một “boilerplate Gin + GORM”). Framework quyết định cấu trúc project. Tốc độ ban đầu tuyệt vời — CRUD sinh ra trong vài giờ. ...

Level 1 – Foundation · Hai nguyên lý cuối của phần nền tảng. Phần A — Separation of Concerns (SoC) 1. Problem Statement Một hàm handler điển hình trong dự án “chạy được là được”: func CreateOrder(w http.ResponseWriter, r *http.Request) { // 1. Parse JSON (concern: giao thức) // 2. Validate input (concern: hợp lệ dữ liệu vào) // 3. Check quyền user (concern: bảo mật) // 4. Tính giá, áp khuyến mãi (concern: NGHIỆP VỤ) // 5. Mở transaction, ghi 3 bảng (concern: lưu trữ, nhất quán) // 6. Ghi log, đẩy metric (concern: vận hành) // 7. Render JSON response (concern: giao thức) } Bảy mối quan tâm (concern), bảy tốc độ thay đổi khác nhau, bảy loại chuyên môn khác nhau — trộn trong một hàm. Muốn sửa một concern phải đọc và hiểu cả bảy; muốn test concern 4 phải dựng đủ 1–7. Đây là dạng tổng quát của mọi vấn đề đã nêu ở các chương trước. ...

Level 1–2 Bridge · Đây là chương kỹ thuật then chốt. Toàn bộ Clean Architecture đứng trên một cơ chế duy nhất được trình bày ở đây. 1. Problem Statement Bài toán Business logic là tài sản quý nhất của hệ thống: nó mã hóa cách doanh nghiệp kiếm tiền, nó sống 10 năm trong khi framework HTTP sống 3 năm và fashion database đổi mỗi 5 năm. Vấn đề: theo cách viết code tự nhiên, thứ quý nhất lại phụ thuộc vào thứ dễ thay đổi nhất. ...

Level 1 – Foundation · Yêu cầu: đã đọc Coupling & Cohesion 1. Problem Statement Chương trước kết luận: kiến trúc tốt = coupling thấp + cohesion cao. Nhưng đó là đại lượng đo, không phải quy tắc hành động. Khi đứng trước một PR, engineer cần câu trả lời cụ thể: struct này nên tách không? Interface đặt ở đâu? Thêm case vào switch này có ổn không? SOLID (Robert C. Martin tổng hợp, đầu những năm 2000) là năm quy tắc hành động trả lời chính xác các câu hỏi đó. Không có SOLID, mỗi engineer quyết định theo cảm tính → codebase thành tập hợp các phong cách mâu thuẫn, review kiến trúc thành tranh cãi ý kiến cá nhân. ...

Level 1 – Foundation · Đối tượng: Backend Engineer trở lên Đây là chương quan trọng nhất của toàn bộ tài liệu. Nếu bạn hiểu sâu coupling và cohesion, mọi pattern phía sau — SOLID, Dependency Rule, Clean Architecture, DDD — chỉ là hệ quả logic. 1. Problem Statement Bài toán kinh doanh Hãy bắt đầu từ một tình huống có thật, không phải từ lý thuyết. Một công ty e-commerce có hệ thống đặt hàng viết bằng Go, chạy tốt trong 2 năm đầu. Đến năm thứ 3: ...

Tài liệu chuyên sâu dành cho Backend Engineer → Software Architect. Ngôn ngữ minh họa: Go 1.22+, ưu tiên Standard Library. Triết lý: hiểu bản chất và trade-off, không sao chép template. Cách đọc Tài liệu được viết theo chuỗi nhân quả — mỗi chương đứng trên chương trước: Business Problem → Vì sao code khó bảo trì → Coupling → Dependency → SOLID → Clean Architecture ra đời → Dependency Rule → Layer → Production → Trade-off → Khi nào KHÔNG nên áp dụngNgười mới nên đọc tuần tự. Người có kinh nghiệm có thể nhảy thẳng vào Level 3–4, nhưng nếu thấy một kết luận thiếu căn cứ — căn cứ nằm ở Level 1. ...

Đối tượng: Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect, Software Architect. Mạch tư duy: Asset → Threat → Attack → Vulnerability → Defense → Trade-off → Production Best Practice. Chín tập trước xây dựng từ vựng và nguyên lý. Tập cuối này lắp ráp chúng vào các hệ thống thật. Với mỗi loại kiến trúc, ta hỏi: tài sản quan trọng nhất là gì, attacker nhắm vào đâu, và các nguyên lý (CIA, Least Privilege, Defense in Depth, Zero Trust, AuthN/AuthZ, token, TLS, secret) kết hợp thành luồng cụ thể ra sao. Trọng tâm là các luồng: Authentication, Authorization, Token Flow, Refresh Flow, API Gateway, Secret Management, Service-to-Service Authentication. ...

Đối tượng: Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect, Software Architect. Mạch tư duy: Asset → Threat → Attack → Vulnerability → Defense → Trade-off → Production Best Practice. Tập 6 giải thích cơ chế các phòng thủ API đặc thù. Tập này tổng hợp chúng thành một bộ nguyên tắc thực hành vận hành — thứ tự áp dụng, cách chúng khớp vào vòng đời một request, và những nguyên tắc thường bị bỏ sót. Đây là “sổ tay checklist có tư duy” trước khi bước sang các kiến trúc thực tế ở tập cuối. ...

Đối tượng: Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect, Software Architect. Mạch tư duy: Asset → Threat → Attack → Vulnerability → Defense → Trade-off → Production Best Practice. Các tập trước bảo vệ ứng dụng. Tập này bảo vệ nền tảng chạy ứng dụng: máy chủ, mạng, container, secret. Nó đào sâu A05 (Security Misconfiguration) của OWASP. Tư tưởng xuyên suốt: giảm bề mặt tấn công (attack surface) và giới hạn bán kính vụ nổ (blast radius) — mỗi cổng mở, mỗi secret hớ hênh, mỗi container quyền cao là một cánh cửa cho attacker. ...

Đối tượng: Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect, Software Architect. Mạch tư duy: Asset → Threat → Attack → Vulnerability → Defense → Trade-off → Production Best Practice. OWASP Top 10 (phiên bản 2021) là danh sách các hạng mục rủi ro web phổ biến và nghiêm trọng nhất, do cộng đồng bảo mật ứng dụng tổng hợp từ dữ liệu thực tế. Đây không phải một checklist “làm xong là an toàn” — nó là bản đồ các lớp lỗ hổng mà mọi backend engineer phải nhận diện được. Với mỗi mục, ta đi theo bốn câu hỏi bạn yêu cầu: Cơ chế → Attack → Demo → Phòng tránh, kèm trade-off và case study. ...

Đối tượng: Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect, Software Architect. Mạch tư duy: Asset → Threat → Attack → Vulnerability → Defense → Trade-off → Production Best Practice. Tập này trả lời: API khác web app ở điểm nào về mô hình mối đe dọa, khi nào dùng API Key vs Token, vì sao Rate Limiting là bảo mật chứ không chỉ là quản lý tài nguyên, Replay Attack là gì và vì sao Idempotency vừa là tính đúng đắn vừa là phòng thủ, và khi nào cần Request Signing/HMAC thay vì token thường. ...

Đối tượng: Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect, Software Architect. Mạch tư duy: Asset → Threat → Attack → Vulnerability → Defense → Trade-off → Production Best Practice. TLS (Tập 4) bảo vệ dữ liệu trên đường truyền. Nhưng khi dữ liệu đã tới trình duyệt, một mặt trận hoàn toàn khác mở ra. Tập này trả lời: vì sao trình duyệt cần Same-Origin Policy, CORS nới lỏng (chứ không siết chặt) bảo mật ra sao, XSS và CSRF khác nhau ở bản chất nào, và vì sao ba cờ cookie nhỏ bé (Secure, HttpOnly, SameSite) lại là tuyến phòng thủ quan trọng bậc nhất. ...

Đối tượng: Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect, Software Architect. Mạch tư duy: Asset → Threat → Attack → Vulnerability → Defense → Trade-off → Production Best Practice. Tập này trả lời: TLS thực sự bảo vệ điều gì (và điều gì nó không bảo vệ), vì sao “có ổ khóa xanh” không đồng nghĩa với “an toàn”, certificate và CA giải bài toán tin cậy ra sao, TLS handshake diễn ra thế nào bên trong, và khi nào cần Mutual TLS. ...

Đối tượng: Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect, Software Architect. Mạch tư duy: Asset → Threat → Attack → Vulnerability → Defense → Trade-off → Production Best Practice. Tập này trả lời những câu hỏi cốt lõi mà mọi backend engineer phải nắm: vì sao MD5 không còn an toàn, vì sao SHA — dù là hàm băm mật mã mạnh — lại không phù hợp để lưu password, vì sao bcrypt/scrypt/Argon2 được thiết kế khác hẳn SHA, và vì sao ta phải cố tình làm cho quá trình hash chậm lại. ...

Đối tượng: Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect, Software Architect. Mạch tư duy: Asset → Threat → Attack → Vulnerability → Defense → Trade-off → Production Best Practice. Tập này đi từ First Principles. Chúng ta sẽ không bắt đầu bằng “JWT là một chuẩn token”. Thay vào đó, chúng ta bắt đầu từ câu hỏi gốc: nếu HTTP không nhớ bạn là ai, thì làm sao một hệ thống biết bạn đã đăng nhập? Từ đó, mỗi cơ chế xác thực sẽ hiện ra như một câu trả lời cho một điểm đau cụ thể của cơ chế trước nó. ...

Đối tượng: Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect, Software Architect. Cách đọc tài liệu này: Đây không phải là một bảng tra cứu kỹ thuật. Mỗi chủ đề được trình bày theo một mạch tư duy cố định: Asset → Threat → Attack → Vulnerability → Defense → Trade-off → Production Best Practice. Bạn sẽ không thấy tài liệu bắt đầu bằng “X là…”. Thay vào đó, mỗi phần bắt đầu bằng câu hỏi: “Nếu không có cơ chế này thì chuyện gì xảy ra?” — vì đó chính là cách một attacker và một architect cùng nhìn vào hệ thống. ...

Bộ tài liệu 10 tập về Backend Security, viết cho Backend Engineer, Senior Backend Engineer, Tech Lead, Solution Architect và Software Architect. Triết lý: không giải thích “cách dùng”, mà giúp người đọc hiểu bản chất — attacker suy nghĩ thế nào, vì sao cơ chế bảo mật tồn tại, nó bảo vệ điều gì, bị khai thác ra sao, và khi nào không nên dùng. Cách bộ tài liệu được xây dựng Mỗi chủ đề bám một mạch tư duy cố định, không bắt đầu bằng định nghĩa: ...

Các chương trước dạy nguyên liệu (cache, queue, shard, replication…). Chương này dạy cách nấu — dẫn dắt một buổi system design 45 phút end-to-end. Khác biệt cốt lõi: system design không kiểm tra bạn biết bao nhiêu công nghệ, mà kiểm tra bạn dẫn dắt sự mơ hồ thành một thiết kế có cơ sở thế nào. Interviewer đóng vai khách hàng mơ hồ; bạn phải hỏi đúng, ước lượng, vẽ, rồi đào sâu. ...

Câu 1 — [Fundamental → Senior] TCP hoạt động thế nào? TIME_WAIT là gì và tại sao nó làm cạn kiệt kết nối? 1. Câu hỏi “Trình bày TCP 3-way handshake và connection lifecycle. TIME_WAIT là gì, tại sao tồn tại, và tại sao nó gây sự cố ‘cannot assign requested address’ trên production?” 2. Interviewer muốn kiểm tra điều gì? Kiến thức mạng nền tảng — nền của mọi thứ backend, và là nơi phân biệt người hiểu sâu. Nối được lý thuyết (TCP states) với sự cố thật (port exhaustion, connection pool). Hiểu tại sao connection reuse (keep-alive, pooling) quan trọng. 3. Câu trả lời ngắn gọn (30 giây) “TCP thiết lập kết nối qua 3-way handshake (SYN → SYN-ACK → ACK) để hai bên đồng bộ sequence number và xác nhận cả hai gửi/nhận được. Đóng kết nối qua 4 bước (FIN/ACK mỗi chiều). Bên chủ động đóng rơi vào TIME_WAIT ~2×MSL (thường 60s trên Linux) trước khi giải phóng hoàn toàn — để nuốt các packet lạc đường của kết nối cũ và đảm bảo bên kia nhận được ACK cuối. Sự cố: một service mở nhiều kết nối ngắn ra ngoài (mỗi request một connection tới upstream) và chủ động đóng → hàng chục nghìn socket kẹt TIME_WAIT chiếm hết ephemeral port (~28k mặc định) → ‘cannot assign requested address’, không mở được kết nối mới dù CPU/RAM rảnh. Fix gốc: tái sử dụng kết nối (keep-alive, connection pool) để đừng tạo-hủy liên tục.” ...

Câu 1 — [Fundamental → Senior] JWT vs Session: khác nhau bản chất ở đâu, và tại sao thu hồi JWT lại khó? 1. Câu hỏi “So sánh session-based auth và JWT. JWT có ưu điểm stateless — nhưng làm sao anh thu hồi (revoke) một JWT trước khi nó hết hạn?” 2. Interviewer muốn kiểm tra điều gì? Hiểu bản chất stateful vs stateless của hai mô hình, không chỉ “JWT hiện đại hơn”. Nhận ra ưu điểm lớn nhất của JWT (stateless) chính là nhược điểm lớn nhất (không revoke được) — câu bẫy kinh điển. Kinh nghiệm thật với refresh token, token rotation, và các đánh đổi. 3. Câu trả lời ngắn gọn (30 giây) “Session: server lưu trạng thái đăng nhập (session store — Redis/DB), client chỉ giữ session ID; muốn logout/revoke thì xóa ở server — tức thời, nhưng mỗi request phải tra store (stateful, cần chia sẻ store khi scale). JWT: token tự chứa thông tin + chữ ký, server chỉ verify chữ ký không cần tra store — stateless, scale ngang dễ, nhưng không revoke được vì server không giữ trạng thái gì để xóa. Token đã phát là hợp lệ tới khi hết hạn. Giải pháp thực dụng: access token sống ngắn (5–15 phút) + refresh token sống dài lưu ở server (revoke được); muốn revoke ngay thì thêm blocklist — nhưng blocklist khiến JWT không còn stateless nữa, đó chính là nghịch lý.” ...

Câu 1 — [Intermediate → Senior] Clean Architecture / Hexagonal Architecture: giải quyết vấn đề gì và khi nào là over-engineering? 1. Câu hỏi “Trình bày Clean/Hexagonal Architecture. Nó giải quyết vấn đề gì thật sự, và khi nào áp dụng nó là sai lầm?” 2. Interviewer muốn kiểm tra điều gì? Hiểu nguyên lý gốc (dependency rule) thay vì thuộc tên các vòng tròn. Đủ trưởng thành để nói về mặt trái — ứng viên chỉ ca ngợi pattern là red flag. Kinh nghiệm thật: đã thấy cả codebase được cứu lẫn codebase bị giết bởi nó. 3. Câu trả lời ngắn gọn (30 giây) “Cả hai chung một nguyên lý: business logic không được phụ thuộc vào chi tiết hạ tầng — dependency chỉ theo một chiều, từ ngoài (DB, HTTP, framework) vào trong (domain), thông qua interface (port) do domain định nghĩa và adapter hiện thực ở ngoài. Lợi ích thật: test business logic không cần DB, đổi hạ tầng không đụng domain, và quan trọng nhất — buộc dev phát biểu nghiệp vụ tách khỏi kỹ thuật. Là over-engineering khi: service CRUD mỏng không có nghiệp vụ (interface + 4 layer để bọc một câu SELECT), hoặc team áp dụng máy móc đủ vòng tròn mà không hiểu mục đích — abstraction có giá, chỉ trả khi domain đủ phức tạp để hoàn vốn.” ...

PHẦN A — MESSAGE QUEUE Câu 1 — [Intermediate → Senior] Kafka hoạt động thế nào? Tại sao nó đạt throughput hàng triệu message/giây? 1. Câu hỏi “Kiến trúc Kafka: topic, partition, consumer group, offset. Điều gì cho phép Kafka nhanh như vậy trên phần cứng thường?” 2. Interviewer muốn kiểm tra điều gì? Hiểu Kafka là distributed log, không phải message queue truyền thống — khác biệt định hình mọi tính chất. Giải thích được nguồn hiệu năng bằng cơ chế cụ thể (sequential I/O, zero-copy, batching), không phải “Kafka nhanh vì được thiết kế tốt”. Nắm ordering, rebalance, lag — các khái niệm vận hành hằng ngày. 3. Câu trả lời ngắn gọn (30 giây) “Kafka là log phân tán: topic chia thành partition, mỗi partition là file log append-only có thứ tự; message không bị xóa khi đọc mà giữ theo retention; consumer tự quản offset của mình. Consumer group chia partition cho các consumer — scale đọc bằng cách thêm consumer tới tối đa = số partition. Nhanh nhờ: ghi/đọc tuần tự trên đĩa (nhanh gần bằng RAM, tận dụng page cache OS), zero-copy (sendfile — dữ liệu từ page cache thẳng ra socket không qua user space), batching + nén cả lô, và broker cực kỳ ’ngu’ — không track trạng thái từng message như RabbitMQ, chỉ là cái log có index.” ...

PHẦN A — MONGODB Câu 1 — [Intermediate → Senior] Replica Set hoạt động thế nào? Điều gì xảy ra khi failover? 1. Câu hỏi “Trình bày cơ chế replica set của MongoDB: bầu chọn, oplog, và các mức write/read concern. Khi primary chết, dữ liệu có thể mất không?” 2. Interviewer muốn kiểm tra điều gì? Hiểu consensus/election thực tế (Raft-like) chứ không chỉ “có 3 node tự failover”. Nắm write concern / read concern — nơi ẩn chứa các quyết định mất-hay-không-mất dữ liệu. Kinh nghiệm với rollback sau failover — thứ ít người biết cho tới khi gặp. 3. Câu trả lời ngắn gọn (30 giây) “Replica set gồm 1 primary nhận ghi và các secondary kéo oplog (log thao tác idempotent) để replay. Election dựa trên giao thức giống Raft: cần đa số phiếu, node có oplog mới nhất được ưu tiên; vì cần majority nên phải có số node lẻ hoặc arbiter. Có mất dữ liệu không phụ thuộc write concern: w:1 (ack từ primary) — ghi chưa kịp replicate sẽ bị rollback khi failover; w:majority — an toàn qua failover, đổi lấy latency. Read concern và read preference quyết định bạn đọc thấy gì và từ đâu.” ...

Câu 1 — [Fundamental → Senior] Tại sao PostgreSQL cần MVCC? Nó hoạt động thế nào và cái giá phải trả là gì? 1. Câu hỏi “Tại sao PostgreSQL cần MVCC? Trình bày cơ chế và hệ quả của nó.” 2. Interviewer muốn kiểm tra điều gì? Hiểu bài toán gốc: concurrency control — reader và writer tranh chấp thế nào. Hiểu cơ chế bên trong (tuple version, xmin/xmax, snapshot) chứ không chỉ khẩu hiệu “reader không chặn writer”. Kinh nghiệm production với hệ quả: bloat, vacuum, wraparound. 3. Câu trả lời ngắn gọn (30 giây) “Không có MVCC, để đọc dữ liệu nhất quán, reader phải lock chặn writer và ngược lại — throughput sụp đổ khi mixed workload. MVCC giải quyết bằng cách: UPDATE/DELETE không ghi đè mà tạo phiên bản tuple mới; mỗi tuple mang xmin/xmax (transaction tạo/xóa nó); mỗi transaction cầm một snapshot và chỉ ’nhìn thấy’ các version phù hợp snapshot của mình. Kết quả: reader không bao giờ chặn writer. Cái giá: các version chết tích tụ thành bloat, cần VACUUM dọn dẹp, và transaction ID 32-bit cần chống wraparound — đây là nguồn của phần lớn sự cố vận hành Postgres.” ...

Câu 1 — [Fundamental → Senior] Event Loop hoạt động thế nào? Tại sao Node single-thread mà vẫn xử lý được hàng chục nghìn kết nối? 1. Câu hỏi “Trình bày các phase của event loop. Node.js ‘single-threaded’ — điều đó đúng đến mức nào?” 2. Interviewer muốn kiểm tra điều gì? Hiểu mô hình thực thi nền tảng — mọi bug hiệu năng Node đều quy về đây. Phân biệt được microtask vs macrotask — nguồn của các bug thứ tự thực thi. Biết giới hạn của mô hình: CPU-bound giết Node như thế nào. 3. Câu trả lời ngắn gọn (30 giây) “Node chạy JavaScript trên một thread duy nhất, nhưng I/O được libuv ủy quyền cho kernel (epoll/kqueue) hoặc thread pool (mặc định 4 thread cho file I/O, DNS, crypto). Event loop quay qua các phase: timers → pending callbacks → poll (chờ I/O) → check (setImmediate) → close. Giữa mỗi callback, toàn bộ microtask queue (promise, process.nextTick) được xả sạch. Node xử lý được C10K vì thread không bao giờ chờ I/O — nó chỉ chạy callback. Điểm chết: một callback tính toán nặng chặn toàn bộ loop, mọi request khác đứng hình.” ...

Câu 1 — [Fundamental → Senior] Goroutine khác gì OS thread? Giải thích mô hình GPM. 1. Câu hỏi “Goroutine là gì, khác gì OS thread? Trình bày cách Go scheduler hoạt động (mô hình GPM).” 2. Interviewer muốn kiểm tra điều gì? Hiểu cơ chế bên trong runtime, không chỉ dùng go func() như hộp đen. Phân biệt được user-space scheduling vs kernel scheduling. Biết hệ quả thực tế: khi nào goroutine “rẻ”, khi nào nó gây ra sự cố. 3. Câu trả lời ngắn gọn (30 giây) “Goroutine là đơn vị thực thi do Go runtime quản lý trong user space, stack khởi đầu ~2KB và co giãn được, chi phí tạo và context switch rẻ hơn OS thread hàng trăm lần. Runtime dùng mô hình GPM: G là goroutine, M là OS thread, P là logical processor giữ run queue. Scheduler multiplex hàng triệu G lên số ít M thông qua P (mặc định P = số CPU core). Nhờ đó Go xử lý được hàng trăm nghìn kết nối đồng thời mà không cần thread pool thủ công.” ...

Viết bởi góc nhìn của một Principal Software Architect đã phỏng vấn hàng trăm ứng viên Senior/Staff/Principal. Mục tiêu: không phải học thuộc đáp án, mà là học cách tư duy. Danh sách chương Chủ đề Trọng tâm Golang Internals GPM, Channel, GC, Escape Analysis, Concurrency Patterns Node.js Internals Event Loop, Stream, Worker Thread, Memory Leak PostgreSQL MVCC, WAL, Vacuum, Isolation, Planner, Replication MongoDB, Redis, ClickHouse Replica Set, Sharding, Distributed Lock, MergeTree Message Queue & API Kafka, RabbitMQ, SQS, NATS, REST/gRPC/GraphQL/WebSocket Architecture & System Design DDD, Microservices, CQRS, Saga, HA, Multi-region, Observability Security & Authentication JWT/Session, OAuth2/OIDC, OWASP, Password/Secrets, mTLS Networking, Linux/OS & K8s TCP/TIME_WAIT, HTTP/2/3, TLS, epoll/OOM, Container, Probes, Deploy System Design Case Studies Framework 45’, Rate Limiter, URL Shortener, Notification, Payment Cấu trúc mỗi câu hỏi (11 mục) Câu hỏi — kèm nhãn độ khó: Fundamental → Intermediate → Senior → Staff → Principal Interviewer muốn kiểm tra điều gì Câu trả lời ngắn gọn (30 giây) — elevator answer Câu trả lời Senior Level (3–5 phút) — Problem → Why → How → Trade-off → Production Giải thích bản chất — first principles Trade-off Ví dụ Production Những câu trả lời chưa đủ tốt Sai lầm phổ biến của ứng viên Follow-up Questions Liên hệ với Production Cách interviewer thực sự tư duy — đọc kỹ trước khi ôn 1. Interviewer không tìm người biết đáp án. Họ tìm người hiểu hệ quả. Khi tôi hỏi “Tại sao PostgreSQL cần MVCC?”, tôi không quan tâm bạn định nghĩa MVCC đúng hay không — Google làm được việc đó. Tôi quan tâm: ...

Cách đọc: mỗi mục trả lời năm câu hỏi — chọn gì, vì sao, vì sao KHÔNG chọn phương án khác, scale/chi phí dự kiến, và rủi ro chính. Các con số là mức định cỡ (order of magnitude) để lập luận, không phải cam kết hiệu năng. 6.1. E-commerce Phân rã workload: đơn hàng/thanh toán/tồn kho (transactional, bất biến chặt) · catalog sản phẩm (schema đa dạng, đọc nhiều) · hành vi người dùng + funnel (event, tỷ row) · giỏ hàng/session (nóng, TTL). ...

Nguyên tắc đọc chương này: ba hệ không cùng hạng cân trên cùng một trục. So sánh đúng nghĩa là ánh xạ workload → điểm mạnh cấu trúc, không phải tìm “database tốt nhất”. Mỗi ô dưới đây là hệ quả của kiến trúc đã phân tích ở Chương 2–4; khi nghi ngờ, quay lại chương tương ứng để xem “vì sao”. 5.1. Bảng so sánh tổng hợp Tiêu chí PostgreSQL MongoDB ClickHouse Data Model Quan hệ (bảng, JOIN, constraint) + JSONB làm van linh hoạt Document (BSON), embed/reference, schema-on-read Bảng phẳng columnar, denormalize có chủ đích, không quan hệ Transaction ACID đầy đủ, Serializable thật, transactional DDL — chuẩn vàng ACID trong 1 document (luôn); đa document từ 4.0 — dùng như ngoại lệ, không hàng ngày Gần như không (atomic theo block insert; không đa statement) — theo thiết kế Query Capability Giàu nhất: SQL đầy đủ, CTE, window, lateral, geo, full-text, vector Giàu theo trục document: CRUD + aggregation pipeline; JOIN yếu SQL analytics rất mạnh (aggregate, window, hàm xấp xỉ); JOIN lớn hạn chế; không tối ưu cho OLTP query Read Performance Point lookup/OLTP xuất sắc (B+Tree + buffer pool); analytics lớn kém Point/one-trục xuất sắc khi có index + đủ RAM; analytics lớn kém Point lookup kém (cấu trúc); scan/aggregate hàng tỷ row: nhanh hơn 2 hệ kia 10–1000× Write Performance Tốt (chục nghìn TPS đơn giản/máy tốt); trần = 1 máy; update-heavy chịu thuế vacuum Tốt + scale-out ghi qua sharding; per-document atomic rẻ Ingest batch cực cao (triệu row/s/node); ghi lẻ tẻ = sự cố; update/delete đắt Analytics Đủ cho báo cáo vừa (parallel query, partition); đuối từ trăm triệu row Aggregation operational tốt; analytical toàn dataset yếu Sinh ra để làm việc này Horizontal Scaling Read replica dễ; sharding không tích hợp (Citus/app-level) Tích hợp, trưởng thành (mongos, balancer, reshard 5.0+) Tích hợp (Distributed table) nhưng thủ công hơn Mongo; Cloud tách compute/storage Compression Khiêm tốn (TOAST cho giá trị lớn; không nén page mặc định) Tốt (block compression WiredTiger, prefix index) Xuất sắc (5–20×, codec chuyên dụng theo cột) Storage Efficiency Trung bình; bloat nếu vacuum không theo kịp Khá; thuế tên field lặp, bù bằng nén Tốt nhất cho analytics; part immutable + TTL/tiered Consistency Mạnh mặc định; single-leader rõ ràng Tunable per-operation (w/readConcern) — mạnh khi cấu hình đúng Eventual giữa replica; đủ cho analytics, không cho nghiệp vụ Availability Cao nhưng failover cần tầng ngoài (Patroni/managed) Cao, failover tự động tích hợp (~10–30s) Cao cho đọc (multi-replica); ghi cần thiết kế ingest chịu lỗi Operational Complexity Thấp–vừa (1 node/RS); vacuum + pooler là hai môn bắt buộc Vừa (replica set dễ); sharded cluster = bậc phức tạp mới Vừa–cao tự quản (Keeper, merge, ingest pipeline); thấp nếu Cloud Cost Rẻ nhất ở quy mô nhỏ–vừa; đắt khi ép làm analytics lớn (máy khủng) Hạ tầng RAM-heavy; Atlas tiện nhưng đắt ở scale Chi phí/TB analytics thấp nhất (nén + máy thường); tốn đầu tư ingest Learning Curve SQL phổ cập; nội tạng (vacuum, planner) cần thời gian Bắt đầu dễ nhất; modeling ĐÚNG khó hơn vẻ ngoài nhiều SQL quen; tư duy OLAP (batch, ORDER BY key, denormalize) phải học lại Best Use Cases Hệ giao dịch, tiền, tồn kho, SaaS core, dữ liệu quan hệ bất kỳ Catalog/profile/content đa dạng schema, IoT theo thiết bị, scale-out một-trục Event/log/metric/clickstream, dashboard real-time, time-series lớn Worst Use Cases Analytics tỷ row; write scale-out; queue tần suất cực cao Quan hệ chặt + bất biến phức tạp; BI toàn dataset OLTP bất kỳ; dữ liệu nhỏ; update thường xuyên 5.2. Ba trục phân tích sâu Trục 1 — Mô hình dữ liệu quyết định 80% quyết định Ba câu hỏi theo thứ tự: ...

Tiền đề: Chương 1 (columnar vs row, LSM, vectorized execution) và các chương PostgreSQL/MongoDB để đối chiếu. Chủ đề trung tâm của chương: ClickHouse nhanh không phải vì “code giỏi hơn”, mà vì nó từ bỏ một cách có chủ đích những thứ OLAP không cần. 1. Problem Statement Bài toán: trả lời câu hỏi phân tích (aggregation, group by, filter) trên hàng tỷ đến hàng nghìn tỷ row trong dưới một giây, với dữ liệu mới đến liên tục. ...