System Design — Bài 15: Framework phỏng vấn System Design trong 40 phút

Một sơ đồ đúng nhưng không giải thích được luồng request sẽ khó thuyết phục người nghe. Trong 40 phút, bạn cần chọn thông tin đủ để bảo vệ quyết định và còn thời gian kiểm tra điểm yếu. Bài này biến kiến thức các phần trước thành một quy trình luyện tập lặp lại được.

Khóa học System Design: mục lục 21 bài — bạn đang đọc bài 15.

Vì sao phỏng vấn System Design khó

Đề thường ngắn nhưng phạm vi rất rộng. “Thiết kế một ứng dụng chat” có thể bao gồm vài nghìn người trong công ty hoặc hàng triệu kết nối toàn cầu. Nếu tự đoán phạm vi rồi vẽ ngay, bạn có thể dành phần lớn thời gian giải sai vấn đề.

Khó khăn thứ hai là không có một đáp án duy nhất. Người phỏng vấn theo dõi cách bạn đặt giả định, dùng số liệu và điều chỉnh khi có yêu cầu mới. Nói “tùy” mà không chỉ ra tùy yếu tố nào thì chưa thể hiện được khả năng ra quyết định.

Khi thiếu kiến thức sản phẩm, hãy quay về nguyên lý: access pattern, tài nguyên, consistency và failure mode. Có thể nói rõ điểm cần kiểm chứng, đưa phương án ban đầu và điều kiện khiến mình đổi phương án. Cách lập luận này đáng tin hơn khẳng định chắc một khả năng chưa biết.

Bốn bước, làm theo đúng thứ tự

Với phiên bốn mươi phút, có thể dành khoảng năm phút làm rõ yêu cầu, năm phút ước lượng, mười lăm phút thiết kế tổng thể, mười phút đào sâu và năm phút kiểm tra lỗi cùng tổng kết. Đây là khung tự luyện, cần điều chỉnh theo tín hiệu của người phỏng vấn.

Ở bước tổng thể, viết một vài API đại diện và mô hình dữ liệu trước. Sau đó đi theo một lượt ghi và một lượt đọc. Mỗi thành phần thêm vào phải giải quyết một nhu cầu đã nêu. Nếu chưa có yêu cầu replay, đừng thêm log phân tán chỉ để sơ đồ đầy đủ.

Deep dive nên chọn một hoặc hai điểm chi phối thiết kế. Với ví là chống trùng và giữ bất biến số dư; với feed là fan-out. Nếu phát hiện mâu thuẫn, sửa sơ đồ và nói lý do thay vì cố bảo vệ phương án ban đầu bằng mọi giá.

Vẽ sơ đồ cho người khác đọc được

Mỗi hộp cần tên và trách nhiệm. Mỗi mũi tên quan trọng cần hướng và ý nghĩa, chẳng hạn gọi API, phát event hoặc tra định tuyến. Nếu dùng nét liền cho sync và nét đứt cho async, ghi legend và giữ nhất quán.

Đừng nhồi mọi chi tiết vào một hình. Vẽ đường chính trước, rồi tách phần deep dive khi cần. Phân biệt đường dữ liệu với control plane như discovery hoặc cập nhật cấu hình, vì chúng không nhất thiết xảy ra trên mỗi request.

Màu giúp làm rõ vai trò nhưng không nên là tín hiệu duy nhất. Một nhãn “nguồn sự thật” hoặc “cache có thể cũ” hữu ích hơn tô màu mà không giải thích. Sau khi vẽ, tự đóng vai người mới và đi qua một request để phát hiện mũi tên thiếu.

Trình bày để người nghe theo kịp

Hãy mở đầu từ vấn đề: “Luồng này đọc nhiều hơn ghi 100 lần, nên em muốn đường đọc ngắn.” Sau đó nói ý tưởng, đi qua high-level rồi mới đào vào cache miss, collision hoặc lỗi mạng. Kết thúc bằng cách ý tưởng đáp ứng yêu cầu và chi phí còn lại.

Hình và lời nên bổ sung nhau. Nếu sơ đồ có Redis, phần trình bày cần giải thích tại sao cache dữ liệu đó, khi nào dữ liệu hết hạn và nếu Redis lỗi thì đường đọc ra sao. Chỉ đọc lại tên hộp khiến người nghe thiếu lập luận.

Sau mỗi đoạn, dừng ngắn để kiểm tra người nghe theo kịp. Trong tự luyện, thu lại phần trình bày rồi xem có quá nhiều giả định ngầm, thuật ngữ chưa giải nghĩa hoặc đoạn chuyển ý đột ngột không. Giao tiếp là kỹ năng có thể cải thiện bằng quan sát chính mình.

Khung thời gian cho một lần tự luyện

00-05 phút: FR, NFR, phạm vi và giả định
05-10 phút: QPS, dung lượng, peak và nút thắt dự kiến
10-25 phút: API -> mô hình dữ liệu -> đường ghi/đọc
25-35 phút: đào sâu 1-2 điểm khó nhất
35-40 phút: lỗi từng phần, recovery và đánh đổi còn lại

Câu trình bày:
Với yêu cầu X, tôi chọn A vì Y.
Chi phí là Z; nếu điều kiện W thay đổi, tôi sẽ xem lại A.

Đây là lịch tự luyện, không phải quy tắc của mọi cuộc phỏng vấn. Nếu người phỏng vấn thay đổi ràng buộc, hãy cập nhật giả định và sơ đồ. Mũi tên phải có ý nghĩa như gọi đồng bộ, phát event hoặc tra định tuyến.

Thuật ngữ cần nhớ

• FR — Functional Requirements: Yêu cầu chức năng: hệ thống phải làm được gì cho ai, ví dụ tạo liên kết ngắn hoặc chuyển tiền.

• NFR — Non-functional Requirements: Yêu cầu phi chức năng: mức chất lượng và ràng buộc, ví dụ độ trễ, khả dụng, bảo mật và quy mô tải; cần diễn đạt bằng tiêu chí đo được.

• HLD — High-Level Design: thiết kế tổng thể, nêu thành phần, trách nhiệm, dữ liệu và luồng giao tiếp chính.

• LLD — Low-Level Design: thiết kế chi tiết, chẳng hạn state machine, điều kiện cập nhật và cách xử lý đồng thời.

Bài tập tự thực hành

Giải thích một thiết kế trong năm phút.

Gợi ý kiểm tra lời giải

Có vấn đề, giả định, đường ghi/đọc, một đánh đổi và một tình huống lỗi; sơ đồ có nhãn.

Tự kiểm tra sau bài học

• Đi trọn một lượt ghi và đọc trước khi thêm chi tiết.

• Chọn deep dive từ rủi ro chi phối thiết kế.

• Có ít nhất một failure path với trạng thái và cách phục hồi.

Tiếp tục lộ trình

Bài trước — Cấu trúc dữ liệu và concurrency qua bài toán một triệu heartbeat

Bài tiếp — Thiết kế URL Shortener: sinh mã, cache và ánh xạ 1-1

Xem toàn bộ khóa học System Design 21 bài