Hi, I’m Thanh HV 👋

Viết bởi một Principal Engineer, dành cho những kỹ sư muốn đi xa hơn chức danh. Lời mở đầu Tôi đã phỏng vấn hàng trăm kỹ sư và mentor hàng chục người từ Mid lên Senior, từ Senior lên Staff. Có một điều tôi thấy lặp đi lặp lại: hầu hết kỹ sư nghĩ rằng lên Senior là vấn đề của việc biết thêm công nghệ. Họ học Kafka, học Kubernetes, học thêm một ngôn ngữ mới, rồi thắc mắc tại sao sau ba năm vẫn dậm chân tại chỗ. ...

Level 5 – Production Yêu cầu trước: toàn bộ tài liệu — chương này là nơi mọi mảnh ghép gặp nhau Mở đầu: đọc kiến trúc như đọc một chứng minh Sau 26 chương, bạn đã có trong tay một hộp công cụ: đếm và xác suất, graph và cây, DP và greedy, đại số tuyến tính và thống kê, entropy và số học modular. Chương cuối này làm một việc duy nhất: mở nắp capo của mười hệ thống tỷ đô và chỉ tay vào đúng chỗ toán học đang nằm. ...

Level 5 – Production Yêu cầu trước: Chương 11 (Probability), Chương 12 (Hashing), Chương 19 (Number Theory) 1. Problem Statement Hãy tưởng tượng tình huống này: bạn và một người lạ chưa từng gặp nhau, chưa từng trao đổi bất kỳ bí mật nào, đứng ở hai đầu một căn phòng đông người. Mọi câu các bạn nói đều bị cả phòng nghe thấy. Nhiệm vụ: hai người phải thỏa thuận được một con số bí mật mà không ai khác trong phòng biết — dù họ nghe được từng từ. ...

Level 5 – Production Yêu cầu trước: Chương 02 (Set Theory, Functions & Relations), Chương 05 (Counting & Combinatorics), Chương 11 (Probability), Chương 12 (Hashing), Chương 19 (Number Theory) 1. Problem Statement Lúc 14:03:07.421 theo đồng hồ của server tại Singapore, một user bấm nút “Mua”. Lúc 14:03:07.418 — sớm hơn 3 millisecond — theo đồng hồ của server tại Virginia, chính user đó bấm “Hủy đơn”. Câu hỏi tưởng như tầm thường: hành động nào xảy ra trước? ...

Level 5 – Production Yêu cầu trước: Chương 07 (Trees), Chương 09 (Boolean Algebra), Chương 12 (Hashing) 1. Problem Statement Một team xây tính năng autocomplete cho ô tìm kiếm sản phẩm. Dữ liệu: 2 triệu tên sản phẩm. Giải pháp đầu tiên rất tự nhiên: đổ tất cả vào hash map… và bế tắc ngay lập tức. Hash map trả lời “chuỗi này có tồn tại không?” trong O(1) — nhưng autocomplete hỏi câu hoàn toàn khác: “chuỗi nào bắt đầu bằng iph?”. Hash của iph không nói gì về hash của iphone 15 pro — hàm hash tốt cố tình phá hủy mọi cấu trúc của key (chương 12). Truy vấn prefix trên hash map là full scan. ...

Level 5 – Production Yêu cầu trước: Chương 10 (Complexity), Chương 11 (Probability), Chương 12 (Hashing) 1. Problem Statement Bạn đang xây dựng một web crawler quy mô lớn. Trước khi tải một URL, crawler phải trả lời câu hỏi tưởng như tầm thường: “URL này đã crawl chưa?” Cách hiển nhiên: một hash set chứa mọi URL đã thấy. Làm phép tính với 10 tỷ URL, mỗi URL trung bình 80 byte, cộng overhead của hash table (con trỏ, bucket, hệ số load factor): ...

Level 4 – Advanced Mathematics Yêu cầu trước: Chương 07 (Trees), Chương 13 (Divide & Conquer), Chương 17 (Linear Algebra) 1. Problem Statement Bạn nhận một ticket tưởng như đơn giản: “API trả về 10 quán cà phê gần người dùng nhất, p99 dưới 50ms.” Database có 5 triệu địa điểm, mỗi địa điểm là một cặp (latitude, longitude). Bản nháp đầu tiên ai cũng viết được: tính khoảng cách từ người dùng đến từng địa điểm, sort, lấy 10. Đó là 5 triệu phép tính khoảng cách (mỗi phép có sin/cos nếu tính đúng trên mặt cầu) cộng một lần sort — hàng trăm millisecond cho một request. Với 1.000 request/giây, bạn cần một cụm máy chỉ để trả lời câu hỏi “gần đây có gì”. ...

Level 4 – Advanced Mathematics Yêu cầu trước: Chương 10 (Complexity), Chương 14 (Dynamic Programming), Chương 15 (Greedy) 1. Problem Statement Cluster Kubernetes của bạn có 40 node, mỗi node 16 vCPU và 64GB RAM. Có 300 pod cần chạy, mỗi pod khai báo request CPU/memory khác nhau, một số pod phải cùng node với nhau (affinity), một số tuyệt đối không được cùng node (anti-affinity), vài pod cần GPU. Hóa đơn cloud tính theo số node bật. Câu hỏi của sếp rất gọn: “Xếp thế nào để bật ít node nhất?” ...

Level 4 – Advanced Mathematics Yêu cầu trước: Chương 07 (Trees), Chương 11 (Probability), Chương 15 (Greedy) 1. Problem Statement Hãy làm một thí nghiệm mất 30 giây. Lấy một file log text 100MB, chạy gzip: file co lại còn ~25MB — nén được 75%. Lấy một file JPEG 100MB, chạy gzip: file thu được ~99.9MB, thậm chí đôi khi lớn hơn file gốc. Cùng một thuật toán, cùng 100MB đầu vào, một bên nén được 75%, một bên 0%. ...

Level 4 – Advanced Mathematics Yêu cầu trước: Chương 03 (Proof Techniques), Chương 11 (Probability), Chương 12 (Hashing) 1. Problem Statement Ngày 4 tháng 6 năm 1996, tên lửa Ariane 5 của Cơ quan Vũ trụ châu Âu phát nổ 37 giây sau khi rời bệ phóng, mang theo thiết bị trị giá khoảng 370 triệu USD. Nguyên nhân gốc, sau nhiều tháng điều tra: một đoạn code tái sử dụng từ Ariane 4 chuyển giá trị vận tốc ngang từ số thực 64-bit sang số nguyên 16-bit. Ariane 5 bay nhanh hơn Ariane 4; giá trị vượt quá 32767; phép chuyển đổi tràn số; hệ thống dẫn đường tự tắt. Không phải lỗi thuật toán, không phải lỗi logic — chỉ là một con số vượt ra ngoài chiếc hộp chứa nó. ...

Level 4 – Advanced Mathematics Yêu cầu trước: Chương 11 (Probability), Chương 16 (Sorting, Searching & Heap) 1. Problem Statement Một buổi sáng thứ Hai, team backend nhận ticket từ customer support: “Nhiều khách hàng phàn nàn app chậm, có người chờ 3–4 giây mới load xong trang chủ.” Kỹ sư trực mở dashboard, nhìn vào biểu đồ latency của API gateway: average response time = 52ms, ổn định suốt tuần. Anh trả lời ticket: “Hệ thống bình thường, có thể do mạng phía khách hàng.” ...

Level 4 – Advanced Mathematics Yêu cầu trước: Chương 02 (Set Theory, Functions & Relations), Chương 10 (Complexity Analysis), Chương 11 (Probability) 1. Problem Statement Người dùng gõ vào ô tìm kiếm của trang thương mại điện tử: “đồ giữ ấm cho bé mùa đông”. Kho hàng có sản phẩm tên “Áo khoác lông cừu trẻ em” — không chung một từ nào với query. Full-text search truyền thống (kể cả Elasticsearch với inverted index từ chương 10) trả về 0 kết quả: nó tìm từ, không tìm nghĩa. Team thử vá bằng từ điển đồng nghĩa — và nhanh chóng chết chìm: “giữ ấm” ~ “khoác” ~ “len” ~ “nỉ” ~ “lông cừu”…, tổ hợp nổ theo cấp số nhân, tiếng Việt lại còn “bé” ~ “trẻ em” ~ “em bé” ~ “kids”. Không ai bảo trì nổi. ...

Level 3 – Algorithm Mathematics Yêu cầu trước: Chương 05 (Counting & Combinatorics), Chương 10 (Complexity Analysis), Chương 11 (Probability), Chương 13 (Divide and Conquer) 1. Problem Statement Một team backend nhận yêu cầu tưởng như tầm thường: trang admin cần hiển thị “100 đơn hàng giá trị cao nhất trong ngày” từ một bảng 50 triệu dòng. Phiên bản đầu tiên: ORDER BY amount DESC LIMIT 100. Query mất 40 giây và đẩy database vào swap — PostgreSQL đang sort toàn bộ 50 triệu dòng chỉ để vứt đi 49.999.900 dòng đầu ra. ...

Level 3 – Algorithm Mathematics Yêu cầu trước: Chương 10 (Complexity Analysis), Chương 14 (Dynamic Programming) 1. Problem Statement Một team platform triển khai autoscaler tự viết: mỗi khi tải tăng, chọn ngay hành động rẻ nhất tại thời điểm đó — thêm một pod vào node đang trống nhất. Từng quyết định riêng lẻ đều hợp lý. Ba tháng sau, cluster rơi vào trạng thái kỳ dị: pod rải vụn khắp nơi, không node nào trống đủ để nhận workload lớn, và chi phí cao hơn 40% so với phương án xếp lại từ đầu. Không quyết định nào sai — nhưng chuỗi quyết định thì sai. ...

Level 3 – Algorithm Mathematics Yêu cầu trước: Chương 06 (Recurrence), Chương 13 (Divide and Conquer) 1. Problem Statement Mỗi lần bạn gõ git diff, Git phải trả lời một câu hỏi nghe đơn giản: chuỗi thao tác thêm/xóa ngắn nhất để biến file cũ thành file mới là gì? Với hai file 1.000 dòng, số cách “căn chỉnh” hai file với nhau nhiều hơn số nguyên tử trong vũ trụ quan sát được. Vậy mà Git trả lời trong vài mili giây — không phải bằng phép màu, mà bằng một quan sát toán học: hàng tỷ tỷ cách căn chỉnh đó được lắp ráp từ một số lượng rất nhỏ các bài toán con phân biệt, mỗi bài chỉ cần giải đúng một lần. ...

Level 3 – Algorithm Mathematics Yêu cầu trước: Chương 06 (Recurrence), Chương 10 (Complexity Analysis) 1. Problem Statement Năm 2004, Jeffrey Dean và Sanjay Ghemawat công bố paper MapReduce, mô tả cách Google đánh index toàn bộ web — hàng chục tỷ trang — bằng những cụm máy rẻ tiền, hỏng liên tục. Cộng đồng kỹ thuật lúc đó xem đây là một cuộc cách mạng về hệ thống phân tán. Nhưng nếu đọc kỹ paper, ý tưởng cốt lõi không mới: chia bài toán khổng lồ thành các mảnh độc lập, giải từng mảnh, rồi ghép kết quả lại. Đó chính là Divide and Conquer — kỹ thuật mà John von Neumann đã dùng để thiết kế merge sort từ năm 1945, gần 60 năm trước. ...

Level 3 – Algorithm Mathematics Yêu cầu trước: Chương 05 (Counting & Combinatorics — Pigeonhole), Chương 11 (Probability) 1. Problem Statement Tháng 12 năm 2011, tại hội nghị bảo mật 28C3 ở Berlin, hai nhà nghiên cứu trình diễn một cuộc tấn công khiến cả ngành web giật mình: với một request POST duy nhất cỡ vài trăm KB, họ ghim CPU của một server PHP ở mức 100% trong nhiều phút. Không tràn bộ đệm, không SQL injection, không lỗi nào trong code ứng dụng. Vũ khí là toán học: họ tính trước hàng chục nghìn chuỗi có cùng giá trị hash, gửi chúng làm tên tham số form. Hash table đựng tham số — cấu trúc “O(1)” mà mọi framework tin tưởng — suy biến thành một danh sách liên kết dài, mỗi thao tác chèn thành O(n), tổng xử lý một request thành O(n²). PHP, Java, Python, Ruby, ASP.NET đều dính. Các bản vá khẩn cấp được tung ra trong vài tuần, và ngôn ngữ sinh sau như Go được thiết kế với hash seed ngẫu nhiên ngay từ đầu vì bài học này. ...

Level 3 – Algorithm Mathematics Yêu cầu trước: Chương 05 (Counting & Combinatorics), Chương 10 (Complexity Analysis) 1. Problem Statement Ngày 24 tháng 12 năm 2012, Netflix sập đúng đêm Giáng sinh. Nguyên nhân gốc nằm ở AWS Elastic Load Balancer, nhưng điều biến một sự cố cục bộ thành sự cố toàn vùng là thứ khác: khi dịch vụ chập chờn, hàng triệu client retry cùng một lúc, theo cùng một lịch. Mỗi client đều làm điều “đúng đắn” — thử lại sau 1 giây, rồi 2 giây, rồi 4 giây. Nhưng vì tất cả thất bại cùng thời điểm, tất cả cũng quay lại gõ cửa cùng thời điểm, như một đội quân diễu hành làm sập cây cầu bằng nhịp bước đồng bộ. Backend vừa ngóc đầu dậy lại bị đạp xuống. Giải pháp mà mọi cloud provider ngày nay khuyến cáo nghe như một trò đùa: thêm ngẫu nhiên vào thời gian chờ. Sự hỗn loạn có chủ đích cứu hệ thống mà kỷ luật tuyệt đối đã giết chết. ...

Level 3 – Algorithm Mathematics Yêu cầu trước: Chương 03 (Proof Techniques), Chương 06 (Recurrence) 1. Problem Statement Năm 2010, một kỹ sư tại một công ty thương mại điện tử viết đoạn code kiểm tra sản phẩm trùng lặp: với mỗi sản phẩm, duyệt qua toàn bộ danh sách để tìm bản sao. Code chạy hoàn hảo trên môi trường dev với 1.000 sản phẩm — mất 2ms. Sáu tháng sau, catalog đạt 2 triệu sản phẩm, và cron job đó chiếm trọn một CPU core trong 4 giờ mỗi đêm. ...

Level 2 – Discrete Mathematics Yêu cầu trước: Chương 01 (Logic), Chương 02 (Set Theory) 1. Problem Statement Một team analytics cần trả lời câu hỏi tưởng như tầm thường: “hôm qua có bao nhiêu user active, và bao nhiêu user active cả 7 ngày liên tiếp?” Hệ thống có 100 triệu user. Giải pháp đầu tiên: bảng daily_active(user_id, date), mỗi ngày ghi vài chục triệu dòng, câu hỏi “active 7 ngày liên tiếp” trở thành JOIN 7 bảng con — chạy hàng phút, tốn hàng chục GB. ...

Level 2 – Discrete Mathematics Yêu cầu trước: Chương 02 (Set Theory, Functions & Relations), Chương 03 (Proof Techniques), Chương 07 (Trees) 1. Problem Statement Một buổi sáng thứ Hai, hệ thống thanh toán của một công ty fintech đứng hình. Không crash, không error log, không CPU spike — chỉ đơn giản là mọi transaction treo vô hạn. Nguyên nhân: transaction A giữ lock trên bảng accounts và chờ lock trên ledger; transaction B giữ lock trên ledger và chờ lock trên orders; transaction C giữ orders và chờ accounts. Ba transaction chờ nhau theo một vòng tròn khép kín — deadlock. ...

Level 2 – Discrete Mathematics Yêu cầu trước: Chương 03 (Proof Techniques), Chương 06 (Recurrence Relations) 1. Problem Statement Một bảng PostgreSQL chứa 1 tỷ dòng. Bạn chạy SELECT * FROM orders WHERE id = 4815162342 và nhận kết quả sau dưới 1 millisecond. Dừng lại và thấy điều đó vô lý đến mức nào: 1 tỷ dòng, mỗi dòng vài trăm byte — bảng nặng vài trăm GB. Đọc tuần tự từ SSD với tốc độ 2 GB/s mất vài phút. Ngay cả khi toàn bộ dữ liệu nằm sẵn trong RAM, scan tuyến tính 1 tỷ dòng cũng tốn cả giây. Vậy mà database trả lời trong thời gian đủ để ánh sáng đi được 300 km. ...

Level 2 – Discrete Mathematics Yêu cầu trước: Chương 03 (Proof Techniques), Chương 05 (Counting & Combinatorics) 1. Problem Statement Một kỹ sư viết hàm tính giá cho sản phẩm bảo hiểm: giá năm thứ n phụ thuộc vào giá hai năm trước đó theo công thức nghiệp vụ. Cách tự nhiên nhất là dịch thẳng công thức thành đệ quy. Code đúng tuyệt đối, unit test xanh với n = 10, n = 20. Rồi một khách hàng nhập hợp đồng 50 năm — và request treo. Không lỗi, không panic, không log. CPU 100%. Với n = 50, hàm đó thực hiện khoảng hai mươi tỷ lời gọi cho một phép tính mà bản chất chỉ cần 50 phép cộng. ...

Level 2 – Discrete Mathematics Yêu cầu trước: Chương 01 (Logic), Chương 02 (Set Theory, Functions & Relations) 1. Problem Statement Một team platform chuẩn bị release tính năng mới đứng sau 12 feature flags. QA lead hỏi câu tưởng chừng đơn giản: “Chúng ta có cần test mọi tổ hợp bật/tắt không?” Một kỹ sư mở laptop định viết script liệt kê tất cả các tổ hợp ra file để đếm. Script chạy được vài giây thì anh dừng lại và làm phép tính nhẩm: mỗi flag có 2 trạng thái, 12 flags → 2¹² = 4.096 tổ hợp. Nếu thêm 3 môi trường deploy và 4 tier khách hàng, con số thành 4.096 × 3 × 4 = 49.152 kịch bản test. Với 5 phút mỗi kịch bản, đó là 6 tháng làm việc liên tục. ...

Level 1 – Mathematical Thinking Yêu cầu trước: Chương 01 (Logic), Chương 02 (Set Theory, Functions & Relations), Chương 03 (Proof Techniques) 1. Problem Statement Một buổi system design interview. Ứng viên được yêu cầu: “Thiết kế tính năng gợi ý bạn bè cho mạng xã hội”. Ứng viên lập tức nói về microservice, Redis cache, Kafka pipeline, sharding database. Người phỏng vấn ngắt lời bằng một câu hỏi duy nhất: “Khoan — ‘bạn của bạn’ là gì, nói bằng toán?” ...

Level 1 – Mathematical Thinking Yêu cầu trước: Chương 01 (Logic), Chương 02 (Set Theory, Functions & Relations) 1. Problem Statement Năm 1996, tên lửa Ariane 5 nổ tung 37 giây sau khi rời bệ phóng — nửa tỷ đô la bốc hơi vì một phép chuyển đổi số 64-bit sang 16-bit tràn số, trong một module đã chạy hoàn hảo nhiều năm… trên Ariane 4, nơi giá trị đó không bao giờ vượt ngưỡng. Code được test kỹ. Test đều pass. Nhưng test chỉ kiểm tra các giá trị đã từng xảy ra, còn tính đúng đắn là câu khẳng định về mọi giá trị có thể xảy ra. ...

Level 1 – Mathematical Thinking Yêu cầu trước: Chương 01 (Logic) 1. Problem Statement Một kỹ sư viết câu JOIN báo cáo doanh thu theo chi nhánh. Query chạy trên môi trường dev với dữ liệu mẫu: đúng. Đưa lên production: bảng kết quả phình ra gấp 40 lần số dòng thật, tổng doanh thu đội lên tương ứng, và báo cáo gửi CEO sáng hôm sau nói công ty vừa có quý tăng trưởng thần kỳ. Nguyên nhân: điều kiện JOIN thiếu một cột trong khóa ghép — mỗi dòng bảng trái khớp với nhiều dòng bảng phải, và kết quả trở thành một mảnh của tích Descartes thay vì phép khớp một-một mà tác giả tưởng tượng. ...

Level 1 – Mathematical Thinking Yêu cầu trước: Không — đây là chương mở đầu của toàn bộ tài liệu 1. Problem Statement Một team backend nhận ticket: “Tìm tất cả khách hàng chưa từng đặt hàng để gửi email khuyến mãi”. Kỹ sư viết câu SQL trông hoàn toàn hợp lý: SELECT * FROM customers WHERE id NOT IN (SELECT customer_id FROM orders); Query chạy không lỗi, trả về… 0 dòng. Trong khi ai cũng biết có hàng nghìn khách hàng chưa đặt hàng. Không exception, không warning, không log. Nguyên nhân: bảng orders có một dòng với customer_id IS NULL (đơn hàng của khách vãng lai). Và trong logic ba giá trị của SQL, x NOT IN (1, 2, NULL) không bao giờ là TRUE — với mọi x. ...

Toán học không phải là môn học bạn phải “vượt qua” để trở thành lập trình viên. Toán học là ngôn ngữ mô tả và giải quyết vấn đề trong Computer Science. Tài liệu này dành cho ai? Software Engineer, Backend Engineer, Frontend Engineer, Fullstack Engineer, AI Engineer, Data Engineer, Senior Developer và Solution Architect — những người muốn hiểu bản chất toán học đằng sau thuật toán, cấu trúc dữ liệu và hệ thống phần mềm, thay vì chỉ học công thức hoặc học thuộc lời giải. ...

Các bảng so sánh khách quan, gom về một chỗ để tra cứu. Mỗi bảng đánh giá theo: hiệu năng, bảo mật, độ phức tạp, khả năng mở rộng, chi phí vận hành, use case phù hợp. 1. Bitcoin vs Ethereum vs Solana Tiêu chí Bitcoin Ethereum Solana Mục tiêu thiết kế Tiền tệ phi tập trung, bất biến tối đa Nền tảng smart contract tổng quát Hiệu năng cao, chi phí thấp Model UTXO Account Account (song song hóa) Consensus PoW Nakamoto PoS Gasper PoS + PoH + Tower BFT Block time / Finality ~10 phút / probabilistic (~60’ quy ước) 12s / ~13 phút finalized ~400ms / ~13s rooted TPS thực tế ~7 ~15-30 (L1) + L2 ~2.000-4.000 (thực tế, không tính vote) Phí điển hình $0.5-20+ $0.5-50 (L1), cent (L2) ~$0.001-0.05 Smart contract Script rất hạn chế EVM/Solidity — hệ sinh thái lớn nhất Rust/SVM — nhanh, học dốc hơn Yêu cầu node Nhẹ (chạy được trên máy cá nhân) Trung bình (2TB NVMe) Rất nặng (256GB RAM, mạng lớn) Độ ổn định lịch sử Xuất sắc (15+ năm) Rất tốt (finality stall ngắn 2023) Nhiều lần outage toàn mạng 2021-22, cải thiện từ 2023 Phi tập trung Cao nhất Cao (lo ngại: Lido, MEV builder) Thấp hơn (rào cản phần cứng) Use case hợp Store of value, settlement lớn DeFi, tài sản hóa, hạ tầng tổng quát Thanh toán nhỏ, DEX tần suất cao, consumer app Cho backend engineer Tích hợp đơn giản (ít tính năng) Tài liệu/tooling tốt nhất, nhiều pattern chuẩn Model khác biệt (không nonce tuần tự, blockhash hết hạn 60s, compute budget) 2. Account Model vs UTXO (Chi tiết Level 1 §5.4 — bảng đầy đủ tại đó.) Tóm tắt quyết định: cần smart contract/state chung → Account; cần song song + đơn giản + privacy tốt hơn cho thanh toán → UTXO. Chi phí backend: UTXO đắt hơn ở ví (coin selection, change), Account đắt hơn ở gửi tx (nonce management). ...