Backend

1. Problem Statement CPU chỉ có một dòng lệnh; RAM là một khối phẳng. Nhưng ta muốn chạy 500 chương trình “đồng thời”, mỗi cái tưởng mình sở hữu cả máy. Process là câu trả lời: một gói đóng kín gồm (code + data + trạng thái CPU + tài nguyên) mà kernel có thể đóng băng, hồi sinh, cô lập, và thu hồi. Nếu không có process: không chạy được nhiều chương trình; không giết được chương trình treo; một chương trình lỗi kéo sập tất cả; không có khái niệm “quyền của ai”. ...

1. Problem Statement Chương 01 kết luận: cần một trọng tài không thể bị qua mặt. Chương 02 cho thấy phần cứng cung cấp nguyên liệu: privilege ring, trap, interrupt. Chương này trả lời: kernel dựng ranh giới bảo vệ bằng nguyên liệu đó như thế nào, và một chương trình “xin” kernel làm việc qua cơ chế gì. Nếu không có ranh giới user/kernel: mọi process đều đọc được memory của nhau và của kernel (mật khẩu, key, dữ liệu khách hàng); mọi process đều ra lệnh trực tiếp cho disk/NIC (phá nát filesystem, giả mạo packet); không thể có multi-tenant, không thể có cloud. Nếu không có syscall: có ranh giới nhưng không có cửa — chương trình không làm được gì hữu ích. ...

1. Problem Statement Kernel không chạy trong chân không — nó chạy trên CPU thật, RAM thật, với những giới hạn vật lý thật. Mọi quyết định thiết kế lớn của Linux đều là phản ứng trước một giới hạn phần cứng cụ thể. Không hiểu phần cứng thì mọi giải thích về kernel đều thành học thuộc lòng. Nếu bỏ qua chương này: bạn sẽ không hiểu vì sao context switch đắt (cache pollution), vì sao lock contention giết throughput (cache line bouncing), vì sao cùng một đoạn code chạy chậm gấp 3 trên máy 2 socket (NUMA), vì sao kernel có thể giật CPU từ một vòng lặp vô hạn (timer interrupt). ...

1. Problem Statement Bạn có một dịch vụ backend: nhận HTTP request, đọc database, trả JSON. Bài toán kinh doanh rất đơn giản: phục vụ nhiều người dùng nhất có thể, nhanh nhất có thể, trên phần cứng rẻ nhất có thể, và không được sập. Bây giờ hãy thử làm điều đó không có hệ điều hành. Bài tập tư duy này là nền của toàn bộ tài liệu: mỗi lần bạn gặp một cơ chế kernel phức tạp (page table, futex, epoll…), hãy quay lại đây và hỏi — nếu không có nó, mình phải tự làm gì? ...

Bộ tài liệu chuyên sâu về hệ điều hành, tập trung vào Linux, viết cho Backend Engineer, Senior Backend Engineer, Tech Lead và Architect. Mục tiêu không phải là học lệnh Linux — mà là hiểu tại sao hệ thống hoạt động như vậy, điều gì xảy ra bên trong kernel khi backend của bạn chạy trong production, và trade-off đằng sau mỗi quyết định thiết kế. Cách đọc bộ tài liệu này Mỗi chương đi theo một template thống nhất: ...

Chương cuối này là phần “chưng cất” của toàn bộ tài liệu. Sau mười hai chương về cơ chế, pattern, sự cố và kiến trúc, câu hỏi còn lại rất thực dụng: làm gì, tránh gì, và — quan trọng không kém — khi nào đừng làm cả. Tôi cố tình viết chương này theo kiểu có thể in ra dán cạnh bàn on-call: mỗi practice kèm lý do, mỗi anti-pattern kèm hậu quả thật, vì quy tắc không có lý do sẽ bị bỏ qua ngay lần deadline đầu tiên. ...

Hai chương trước cho bạn pattern (chương 10) và bản đồ rủi ro (chương 11). Chương này ghép chúng lại thành thiết kế hoàn chỉnh theo từng loại hệ thống. Cùng một công nghệ — Debezium, Kafka — nhưng bài toán e-commerce, FinTech hay SaaS multi-tenant dẫn đến những quyết định rất khác nhau, và điều làm nên một Solution Architect giỏi không phải là biết công cụ, mà là biết bối cảnh nào bẻ cong thiết kế theo hướng nào. ...

Đây là chương quan trọng nhất của toàn bộ tài liệu. Lý do rất đơn giản: CDC không khó ở lúc setup — CDC khó ở tháng thứ ba vận hành. Demo Debezium chạy trong một buổi chiều; nhưng pipeline CDC production là một chuỗi hệ thống stateful nối tiếp nhau (database → connector → Kafka → consumer → sink), và mỗi mắt xích có những chế độ hỏng riêng, đôi khi âm thầm, đôi khi phá hủy cả database nguồn. ...

Đến chương này, chúng ta đã hiểu CDC hoạt động thế nào ở tầng cơ chế: transaction log, replication slot, connector, offset. Câu hỏi tiếp theo — và là câu hỏi mà một Tech Lead hay Solution Architect thực sự phải trả lời — là: CDC đứng ở đâu trong kiến trúc tổng thể? Nó thay thế cái gì, kết hợp với pattern nào, và quan trọng hơn: nó không phải là cái gì. ...

Hai chương trước cho bạn nguồn (Debezium) và nền tảng (Kafka Connect). Chương này lắp mọi thứ thành pipeline hoàn chỉnh — và quan trọng hơn, chỉ ra các quyết định thiết kế ở giữa hai đầu: topic và partition, schema contract, cách từng loại đích tiêu hóa change event, và latency/backpressure của toàn tuyến. Kinh nghiệm của tôi: pipeline CDC thất bại ở production hiếm khi vì Debezium hay Kafka lỗi — nó thất bại vì các quyết định thiết kế trung gian bị bỏ qua: topic 200 partition cho bảng 50 nghìn row, JSON không schema, insert từng row vào ClickHouse. Cuối chương có đúng ví dụ đó, kèm bản chữa. ...

Chương 7 kết thúc với một nhận định: phần khó nhất của CDC không phải đọc log mà là quản lý trạng thái và fault tolerance — và Debezium đẩy toàn bộ phần đó cho Kafka Connect. Chương này mở hộp đen Kafka Connect từ góc nhìn người vận hành platform. Nếu Debezium là động cơ, Connect là khung gầm: khi pipeline CDC gặp sự cố lúc 3 giờ sáng, thứ bạn thao tác gần như luôn là Connect — REST API, task state, rebalance, internal topic — chứ không phải code Debezium. ...

Ở các chương trước, chúng ta đã phân tích cơ chế log-based CDC ở tầng database: WAL của PostgreSQL, binlog của MySQL, replication slot, logical decoding. Chương này đi vào bên trong Debezium — thành phần đứng giữa database và Kafka — để trả lời câu hỏi mà mọi kiến trúc sư phải trả lời được trước khi đưa Debezium vào production: nó thực sự làm gì bên trong, trạng thái của nó nằm ở đâu, và điều gì xảy ra khi nó chết? ...

Đối tượng: Senior Backend Engineer, Tech Lead, Solution Architect thiết kế pipeline CDC end-to-end. Mục tiêu chương: Hai chương trước đi sâu vào từng nguồn log. Chương này trả lời câu hỏi ở tầng trên: bất kể nguồn là WAL, binlog hay oplog, một CDC connector phải giải năm bài toán bất biến: (1) dựng trạng thái ban đầu khi log không giữ toàn bộ lịch sử; (2) nhớ vị trí đọc để crash không chết pipeline; (3) đảm bảo gì về delivery; (4) đảm bảo gì về thứ tự; (5) sống sót qua schema change. Ai nắm năm bài toán này sẽ đánh giá được mọi công cụ CDC — Debezium hay bất cứ tên nào xuất hiện sau này — bằng cùng một checklist. ...

Đối tượng: Senior Backend Engineer, Tech Lead, Solution Architect vận hành CDC trên MySQL và MongoDB. Mục tiêu chương: Chương 4 đã mổ xẻ WAL của PostgreSQL. Chương này áp cùng khung tư duy lên hai họ database còn lại chiếm phần lớn thị phần CDC: MySQL (binlog) và MongoDB (oplog). Điểm mấu chốt không phải là học ba bộ thuật ngữ — mà là nhận ra ba hệ đã chọn ba mô hình retention và contract khác nhau cho cùng một bài toán, và mỗi lựa chọn sinh ra một failure mode đặc trưng mà bạn, người thiết kế platform, phải phòng thủ theo cách khác nhau. ...

Đối tượng: Senior Backend Engineer, Tech Lead, Solution Architect đang thiết kế hoặc vận hành pipeline CDC trên PostgreSQL. Mục tiêu chương: Sau chương này, bạn phải trả lời được ba câu hỏi mà mọi cuộc review kiến trúc CDC trên PostgreSQL đều xoay quanh: (1) WAL thực chất là gì và vì sao nó là nguồn sự thật duy nhất mà CDC có thể tin; (2) replication slot hoạt động thế nào và vì sao nó là con dao hai lưỡi nổi tiếng nhất của CDC trên PostgreSQL; (3) REPLICA IDENTITY ảnh hưởng gì đến nội dung event và bạn phải trả giá gì cho từng lựa chọn. ...

3.1. Insight nền tảng: dữ liệu về mọi thay đổi đã tồn tại sẵn Hãy quay lại điểm mà Chương 2 dừng lại. Chúng ta cần một nguồn thông tin về thay đổi thỏa mãn ba điều kiện: đầy đủ tuyệt đối (mọi thay đổi, từ mọi đường ghi, kể cả DELETE), atomic với dữ liệu commit (không event ma, không mất event), và không đặt thêm chi phí vào transaction path. ...

Chương 1 đã xác lập bài toán: dữ liệu buộc phải phân mảnh theo workload, và cần một cơ chế đưa thay đổi từ source of truth đến các hệ thống downstream. Chương này đi qua các phương pháp mà ngành đã dùng suốt ba thập kỷ — theo đúng thứ tự tiến hóa của chúng. Đây không phải bài điểm danh lịch sử: mỗi phương pháp vẫn đang chạy trong production ở đâu đó ngay lúc này, và mỗi phương pháp đều dạy ta một bài học về vì sao CDC log-based cuối cùng trở thành câu trả lời. Với mỗi phương pháp, ta phân tích theo cùng một template: cách hoạt động, ưu điểm, hạn chế kỹ thuật, một ví dụ production khi nó fail, và — quan trọng không kém — khi nào nó vẫn là lựa chọn đúng. ...

1.1. Bắt đầu từ một bài toán kinh doanh cụ thể Hãy hình dung một hệ thống e-commerce cỡ vừa: 5 triệu người dùng, 2 triệu SKU, khoảng 300.000 đơn hàng mỗi ngày. PostgreSQL là source of truth — nơi mọi transaction ghi đơn, trừ kho, cập nhật giá diễn ra. Hệ thống chạy tốt trong hai năm đầu. Rồi các yêu cầu sau lần lượt xuất hiện: Search: người dùng cần tìm kiếm sản phẩm theo full-text, fuzzy matching, faceted filter theo thương hiệu, khoảng giá, đánh giá. Đội ngũ chọn Elasticsearch. Analytics: đội business cần dashboard doanh thu theo giờ, phân tích cohort, funnel conversion trên hàng trăm triệu event. Đội data chọn ClickHouse. Cache: trang chi tiết sản phẩm chịu 20.000 request/giây lúc flash sale, không thể đánh thẳng vào PostgreSQL. Đội backend đặt Redis phía trước. Đến đây, cùng một thực thể product tồn tại ở bốn nơi: PostgreSQL (bản gốc), Elasticsearch (bản đánh index cho search), ClickHouse (bản denormalized cho analytics), Redis (bản serialized cho cache). Dữ liệu đã bị phân mảnh (data fragmentation). Và câu hỏi trung tâm của toàn bộ tài liệu này xuất hiện: ...

Bộ tài liệu chuyên sâu về Change Data Capture (CDC) — viết từ góc nhìn của người thiết kế Data Platform và Distributed Systems, không phải từ góc nhìn người dùng công cụ. Đối tượng: Backend Engineer, Data Engineer, Senior Backend Engineer, Tech Lead, Solution Architect, Software Architect. Triết lý trình bày: Business Problem → Vì sao cần đồng bộ dữ liệu → Hạn chế của Polling → Trigger / Dual Write / Event Publishing → CDC → Log-based CDC → Internal Architecture → Trade-off → Production → Khi nào không nên dùng CDC. ...

Module 11 — Kiến trúc thực tế: các hệ thống lớn được xây thế nào và vì sao Mỗi mục dưới đây là một bài tập tổng hợp của 10 module trước. Cấu trúc chung: đặc trưng workload → nó ép ra kiến trúc gì → trade-off và failure case đã trả giá. Điều đáng học không phải sơ đồ — mà là chuỗi suy luận từ workload ra kiến trúc. ...

Module 10 — Security cho Backend Systems Nguyên tắc chi phối toàn module: defense in depth (nhiều lớp — vì mỗi lớp SẼ có lỗ) và least privilege (mọi thứ chỉ được quyền tối thiểu — để khi bị xuyên, blast radius nhỏ nhất). Security không phải tính năng thêm sau; nó là thuộc tính kiến trúc như latency. 1. Authentication & Authorization: TLS/mTLS, JWT, OAuth2 mTLS — máy xác thực máy TLS thường: client xác thực server (module 01). mTLS: cả hai chiều — client cũng trình certificate. Đây là nền của zero-trust nội bộ: không tin “vì cùng mạng nội bộ” (perimeter model chết khi một máy bên trong bị chiếm — kẻ tấn công di chuyển ngang tự do). Vấn đề thật của mTLS không phải crypto mà là vận hành vòng đời cert: cấp phát, xoay ngắn hạn, thu hồi cho hàng nghìn service. Làm tay = bất khả thi; đây chính là lý do dùng service mesh (Istio/Linkerd tự động toàn bộ: SPIFFE identity, cert 24h, xoay tự động) hoặc SPIRE. Nếu không có nhu cầu compliance/zero-trust thật, cân nhắc kỹ trước khi trả chi phí vận hành mesh. ...

Module 09 — Reliability Engineering Tiên đề: mọi thứ đều hỏng. Disk hỏng, mạng phân mảnh, process bị OOM, con người gõ nhầm lệnh, và một ngày nào đó cả region sập. Reliability engineering không phải ngăn hỏng hóc — đó là thiết kế để hệ thống vẫn phục vụ được user khi từng phần của nó đang hỏng. 1. High Availability và Fault Tolerance Toán học nền tảng Availability chuỗi nối tiếp NHÂN với nhau: 5 service 99.9% nối tiếp = 99.5% (43 phút → 3.6 giờ downtime/tháng). Hệ quả khắc nghiệt: chuỗi phụ thuộc càng dài, availability càng tệ hơn mắt xích tệ nhất, và mọi dependency đồng bộ trong critical path đều phải “trả thuế” này. Ngược lại, redundancy song song: 2 bản 99% độc lập = 99.99% — nếu thật sự độc lập. ...

Module 08 — Observability Monitoring trả lời “hệ thống có đang hỏng theo cách tôi đã đoán trước không?”. Observability trả lời “hệ thống đang làm cái quái gì vậy?” — kể cả với lỗi chưa ai từng đoán. Trong hệ phân tán, lỗi thú vị luôn là lỗi chưa ai đoán trước. 1. Problem Statement Một request đi qua 15 service. User báo “chậm”. Không có observability: 15 team nhìn 15 dashboard riêng, ai cũng “service tôi bình thường”, 4 tiếng meeting để tìm ra một connection pool cạn ở service thứ 9. Chi phí thật của thiếu observability đo bằng MTTR (giờ thay vì phút) và bằng những sự cố âm ỉ không ai biết (lỗi 0.5% user suốt 3 tuần). ...

Module 07 — Cloud Infrastructure Cloud không phải “máy tính của người khác cho thuê”. Nó là một mô hình kinh tế + vận hành khác: đổi CAPEX thành OPEX, đổi “quản lý phần cứng” thành “quản lý cấu hình và chi phí”. Module này lấy AWS làm hệ quy chiếu; khái niệm ánh xạ 1-1 sang GCP/Azure. 1. VPC — mạng riêng ảo, nền của mọi thứ Problem Statement Trong datacenter chung của cloud, khách hàng cần một mạng cách ly logic hoàn toàn: tự chọn dải IP, tự quyết định gì nói chuyện với gì, gì thấy Internet. VPC = software-defined network cung cấp đúng điều đó — mọi tài nguyên bạn tạo đều sống trong một VPC, mọi quyết định security/network đầu tiên là quyết định topology VPC. ...

Module 06 — CI/CD và Deployment Strategy CI/CD không phải chuyện công cụ (Jenkins vs GitHub Actions). Nó là bài toán quản lý rủi ro thay đổi: thay đổi là nguồn sự cố số 1 của mọi hệ thống production, và cũng là thứ duy nhất tạo ra giá trị. Mục tiêu: tăng tần suất thay đổi VÀ giảm blast radius của mỗi thay đổi — hai thứ tưởng mâu thuẫn nhưng thực ra cộng hưởng. ...

Module 05 — Kubernetes Kubernetes không phải “công cụ chạy container”. Nó là một hệ điều khiển hội tụ trạng thái (desired state reconciliation). Nắm được mô hình đó, mọi thứ còn lại là chi tiết. 1. Tại sao Kubernetes tồn tại và mô hình tư duy cốt lõi Problem Statement Container giải bài toán đóng gói cho MỘT máy. Ở quy mô nhiều máy, các câu hỏi mới xuất hiện: đặt container nào lên máy nào (bin packing)? Máy chết thì container đi đâu? Traffic tìm container đang di chuyển thế nào? Rollout 200 instance không downtime bằng cách nào? Trước Kubernetes, mỗi công ty tự viết script/orchestrator riêng — Google đúc kết 15 năm chạy Borg thành Kubernetes. ...

Module 04 — Container Điều kiện tiên quyết: Module 03 (namespace, cgroup, OOM). Container không phải VM nhẹ — nó là process Linux được cách ly. Toàn bộ module này triển khai từ câu đó. 1. Tại sao container tồn tại Problem Statement Trước container, deploy có 2 lựa chọn tệ: Cài trực tiếp lên máy: “works on my machine” — app phụ thuộc phiên bản libc, Python, thư viện hệ thống của máy đó. Hai app cần 2 phiên bản khác nhau của cùng thư viện = xung đột. Môi trường dev/staging/prod lệch nhau = lớp bug riêng. VM: cách ly tốt nhưng mỗi VM chở nguyên một kernel + OS: boot hàng phút, tốn GB RAM cho phần không phải app, mật độ thấp. Container giải cả hai: đóng gói app + toàn bộ userspace dependency thành một artifact bất biến (giải quyết “works on my machine”), chạy như process thường trên kernel chung (giải quyết chi phí VM — khởi động ms, overhead ~0). ...

Module 03 — Linux Internals Mọi thứ bạn deploy cuối cùng đều là process trên Linux. Container, Kubernetes, “serverless” — tất cả là abstraction trên các cơ chế trong module này. Hiểu chúng = debug được mọi tầng phía trên. 1. Process, Thread và Scheduler Problem Statement Một CPU chỉ chạy được một luồng lệnh tại một thời điểm, nhưng hệ thống cần chạy hàng nghìn việc “đồng thời”, cách ly lỗi giữa các chương trình, và phân phối CPU công bằng. Process/thread + scheduler là câu trả lời của kernel. ...

Module 02 — Backend Networking Từ “mạng hoạt động thế nào” sang “hệ thống backend nói chuyện với nhau thế nào cho đáng tin cậy ở quy mô lớn”. 1. Connection Lifecycle, Keep-Alive và Connection Pooling Problem Statement Mỗi connection mới có chi phí cố định: TCP handshake (1 RTT) + TLS handshake (1–2 RTT) + slow start (nhiều RTT để đạt throughput). Với RTT 50ms, một HTTPS connection mới tốn ~150–250ms trước khi gửi byte đầu tiên. Service gọi nhau 1000 req/s mà mỗi request mở connection mới thì: latency cộng thêm hàng trăm ms, CPU đốt vào handshake, ephemeral port cạn (TIME_WAIT), file descriptor cạn. ...

Module 01 — Networking Fundamentals Đối tượng: Backend/Senior Engineer trở lên. Mục tiêu: hiểu mạng từ góc nhìn người thiết kế hệ thống — không phải người dùng công cụ. 1. OSI Model và TCP/IP — Tại sao phải chia tầng? Problem Statement Nếu mọi ứng dụng tự lo từ tín hiệu điện đến format dữ liệu, mỗi phần mềm phải viết lại toàn bộ stack mạng, và không phần mềm nào nói chuyện được với phần mềm khác. Bài toán cốt lõi: tách trách nhiệm (separation of concerns) để các hệ thống khác nhau tương tác được mà không cần biết chi tiết của nhau. ...