Docs học tập
Backend nền tảng

Kiến thức nền tảng Backend

66 khái niệm cốt lõi, từ tư duy sản phẩm đến case study.

66 khái niệm backend, chia 10 nhóm. Mỗi khái niệm một trang: ví dụ đời thường, cốt lõi, đánh đổi, bug hay gặp.

Bắt đầu ở 8 ý tưởng lõi, rồi các mục có sao. Junior cộng Middle là đủ nền cho vị trí middle ở phần lớn công ty.

Nhóm

Tư duy sản phẩm

Ôn lại: • Chọn một tính năng bạn đang làm và liệt kê 5 trường hợp ngoại lệ nghiệp vụ của nó. • Vì sao nhiều công ty ngân hàng, SAP yêu cầu kinh nghiệm domain? • Khi AI đề xuất schema 25 bảng, bạn kiểm tra lại theo những câu hỏi nào? NHÓM B · NỀN TẢNG MÁY TÍNH: OS & NETWORK Không cần sâu như kỹ sư hệ thống, nhưng đây là tầng giải thích vì sao service chậm, treo, rò rỉ bộ nhớ hay lỗi kết nối. Khi debug production, gần như lúc nào cũng quay về đây.

OS và Network

Ôn lại: • Giải thích vì sao một tác vụ nặng CPU làm Node.js chậm toàn bộ. • Connection pool giải quyết vấn đề gì, đặt kích thước thế nào? • Vì sao retry không có backoff có thể đánh sập dịch vụ? NHÓM C · NỀN TẢNG SYSTEM DESIGN Năm khối xây dựng xuất hiện trong gần như mọi hệ thống backend. Hiểu chúng giống như có sẵn bộ lego để lắp ráp mọi kiến trúc.

System design

Ôn lại: • Giải thích Consistent Hashing cho người không biết lập trình trong 60 giây. • Vì sao một hệ phân tán không thể chọn CA? • Điều gì xảy ra ở Cache-Aside khi dữ liệu không có trong cache? NHÓM D · DỮ LIỆU & DATA MODELING Dữ liệu là nơi hệ thống thường chậm nhất, dễ hỏng nhất và khó sửa nhất. Nhóm này đi từ thiết kế schema cho đúng và vừa đủ, đến truy vấn, nhất quán và mở rộng.

Dữ liệu

Ôn lại: • Vì sao đơn hàng nên lưu lại giá tại thời điểm mua? • Vì sao index làm đọc nhanh nhưng ghi chậm? • Đổi tên một cột trên bảng đang chạy mà không downtime thế nào? NHÓM E · GIAO DỊCH & ĐỒNG THỜI Khi nhiều người cùng thao tác một lúc, những lỗi khó thấy nhất xuất hiện: mất cập nhật, trừ tiền hai lần, bán quá tồn kho. Chương này giải thích cách giữ dữ liệu đúng.

Giao dịch và đồng thời

Ôn lại: • Kể một tình huống "mất cập nhật" và cách Optimistic Lock ngăn nó. • Vì sao microservices dùng Saga thay vì 2PC? • Distributed lock cần thời gian hết hạn (TTL) để làm gì? NHÓM F · THIẾT KẾ API & BẢO MẬT API là "hợp đồng" giữa hệ thống và thế giới bên ngoài. Một API tốt cần an toàn, không xử lý trùng, dễ mở rộng; và bảo mật cơ bản là yêu cầu tối thiểu ở mọi công ty.

API và bảo mật

Ôn lại: • Vì sao POST /pay cần Idempotency-Key còn GET thì không? • Vì sao dùng ORM vẫn có thể bị SQL injection? • Vì sao lưu mật khẩu phải dùng hàm băm chậm? NHÓM G · KIẾN TRÚC PHÂN TÁN & MESSAGING Hệ thống lớn hiếm khi là một khối duy nhất. Chương này giải thích các service tìm thấy nhau, nói chuyện với nhau và tách rời nhau như thế nào.

Kiến trúc phân tán

Ôn lại: • Khi nào gọi trực tiếp, khi nào đẩy vào hàng đợi? • Vì sao Kafka chỉ đảm bảo thứ tự trong một partition? • API Gateway khác Load Balancer ở đâu? NHÓM H · HẠ TẦNG, TRIỂN KHAI & VẬN HÀNH Code chỉ có giá trị khi chạy ổn định trên production. Nhóm này đi từ container, scaling đến cách đưa code lên an toàn và biết hệ thống đang khỏe hay yếu.

Hạ tầng và vận hành

Ôn lại: • Blue-green và canary khác nhau thế nào, khi nào dùng cái nào? • Log, metrics, tracing mỗi loại trả lời câu hỏi gì? • Kể lại 10 bước khi gõ google.com mà không nhìn tài liệu. NHÓM I · LLD, DESIGN PATTERN & KIỂM THỬ Tổ chức code bên trong cho sạch, dễ mở rộng và có test bảo vệ. Đi từ nguyên lý (SOLID) → mẫu thiết kế → kiểm thử → ví dụ áp dụng.

LLD và kiểm thử

Ôn lại: • Nêu 5 chữ SOLID, mỗi chữ kèm một ví dụ vi phạm. • Vì sao chỉ có unit test với mock là chưa đủ? • Vì sao Strategy giúp tuân thủ nguyên tắc Open/Closed? NHÓM J · CASE STUDY HỆ THỐNG THỰC TẾ Nơi mọi khối kiến thức ở các chương trước được ghép lại thành những hệ thống có thật mà bạn dùng hằng ngày.

Case study

Ôn lại: • Fanout on Write gặp vấn đề gì với tài khoản nổi tiếng? • Vì sao thanh toán cần webhook và đối soát, không chỉ redirect? • Nên dùng redirect 301 hay 302 cho dịch vụ rút gọn URL?

Sau khi học khái niệm

On this page