Cách trả lời phỏng vấn system design — khung làm việc

Chín case study trong series đều cùng hình: từ "thiết kế X" tới kiến trúc chạy được trong 45 phút. Hình là khung, và khung luyện được. Chương này gộp các case study thành một câu trả lời phỏng vấn lặp được.

Vì sao khung quan trọng hơn câu trả lời?

Ba lý do.

Mơ hồ. "Thiết kế Twitter" không có câu trả lời đúng. Người phỏng vấn khác có kiến trúc lý tưởng khác. Cho thấy quy trình - hỏi, ước lượng, biện minh - là cách duy nhất để thể hiện seniority vì không có ground truth.

Thời gian. Bốn mươi lăm phút trôi nhanh. Không có cấu trúc, ứng viên dành 30 phút vẽ hộp và không bao giờ tới deep-dive phân biệt mid với senior.

Áp lực. Người phỏng vấn sẽ ném curveball. Khung cho bạn chỗ đáp khi curveball tới.

Khung sáu bước là gì?

flowchart LR
    Clarify[1. Clarify scope<br/>5 phút] --> Estimate[2. Ước lượng<br/>5 phút]
    Estimate --> Arch[3. Kiến trúc cao<br/>10 phút]
    Arch --> Deep[4. Deep-dive 1 thành phần<br/>15 phút]
    Deep --> Scale[5. Scale-out + failure<br/>5 phút]
    Scale --> Recap[6. Recap<br/>5 phút]

Sáu bước, ~45 phút tổng, có đệm cho câu hỏi. Phần lớn ứng viên bỏ qua 1 và 2; đó là chỗ điểm nhiều nhất sống.

Clarify scope trong năm phút ra sao?

Ba câu hỏi để hỏi, mỗi lần:

• User là ai và geography ở đâu? Dẫn dắt pattern traffic và câu hỏi multi-region.
• Tính năng nào trong scope? "Twitter" gồm timeline, post, search, DM, ads. Chọn ba; hoãn còn lại.
• Tiêu chí thành công là gì? Mục tiêu latency p99, SLO sẵn sàng, yêu cầu nhất quán. Từ vựng chương 1 cho bạn các từ.

Người phỏng vấn tốt sẽ đã viết câu trả lời ưa thích sẵn; bạn hỏi cho họ chỉ bạn vào đó.

Ước lượng tải trong năm phút ra sao?

Dùng hằng số từ chương 2 - 100K giây/ngày, 1 KB mỗi row text, hệ số đỉnh 5x. Tính bốn số trên bảng:

Số tôi sẽ tham chiếu phần còn lại của phỏng vấn:
- DAU            ~100M
- QPS đỉnh       ~50K (read), ~5K (write) sau hệ số 5x
- Storage 1 năm  ~36 TB ở 1 KB mỗi write
- Latency p99    < 100 ms (tính năng tương tác)

Viết trong cột người phỏng vấn thấy. Tham chiếu trong phần thảo luận sau - "5K write/s vừa một node Postgres, nên chưa cần shard". Đây là nước đi phân biệt ứng viên có cấu trúc với người ứng biến.

Vẽ kiến trúc cao trong mười phút ra sao?

Bắt đầu với phiên bản single-node đơn giản nhất, rồi chỉ thêm hộp mà số tải ép. Pattern lặp được xuyên case study:

flowchart LR
    Client --> LB[Load Balancer]
    LB --> App[Service app]
    App --> Cache[(Cache)]
    App --> DB[(DB primary)]
    App --> Q[(Queue)]
    Q --> Worker[Worker async]
    Worker --> External[Service ngoài]
    App --> Obs[(Observability)]

Sáu hộp đủ cho gần như mọi case study. Biện minh mỗi cái bằng số cụ thể từ ước lượng. Cache có vì khuếch đại read (hit 90%); queue có vì side effect dài; DB là Postgres vì write QPS vừa một node.

Deep-dive một thành phần trong mười lăm phút ra sao?

Người phỏng vấn sẽ chỉ một hộp và nói "kể thêm". Đây là chỗ 60% điểm sống. Ba tầng đi qua:

1. Schema hoặc interface - data trông thế nào, API trông thế nào.
2. Thuật toán hoặc pattern - invalidate cache chạy ra sao, queue retry ra sao, saga bù ra sao. Chương reliability là nguồn cho mấy cái này.
3. Failure mode - thành phần này chết thì sao, phát hiện ra sao, phục hồi ra sao.

Luyện deep-dive trên mọi case study trong series. URL shortener (chương 15) deep-dive cache; news feed (chương 17) deep-dive worker fan-out; hệ thống payment deep-dive saga.

Xử "nếu 10x traffic" trong năm phút ra sao?

Lấy số từ bước 2 và nhân. Cho mỗi hộp trong kiến trúc, nói cái đổi:

// Checklist tinh thần "scale tới 10x":
// - Tier app: stateless, thêm replica. KHÔNG đổi.
// - Cache: scale cluster Redis, partition key theo hash. KHÔNG đổi.
// - DB: 5K -> 50K write/s vượt 1 node Postgres. THÊM: shard theo user_id.
// - Queue: 1K -> 10K msg/s vẫn vừa RabbitMQ. KHÔNG đổi.
// - Worker: song song qua consumer group. KHÔNG đổi.
// - Observability: cardinality có thể bùng. THÊM: bỏ label cardinality cao.

Biết điểm nghẽn ở đâu quan trọng hơn biết sửa ra sao. Người phỏng vấn muốn thấy bạn lý luận được thành phần nào vỡ trước.

Recap năm phút cuối ra sao?

Ba câu, trên bảng:

1. "Đây là cái ta xây, với bốn số này."
2. "Đây là kiến trúc, với cache/queue/DB biện minh."
3. "Đây là cái đổi ở 10x và failure mode chính."

Rồi hỏi "muốn tôi đào sâu vào đâu?" - nước đi đóng thường biến phỏng vấn ranh giới thành tuyển.

Luyện trông ra sao?

Chọn một case study từ series mỗi buổi luyện. Đặt timer 45 phút. Che chương; chỉ nhìn cho số ước lượng. Chạy qua sáu bước trên bảng (hoặc giấy). So kiến trúc của bạn với chương. Khoảng cách hẹp lại sau hai ba buổi.

Chín case study phủ tập hợp phỏng vấn chuẩn:

• Read-heavy CRUD: URL shortener
• Write-heavy fan-out: news feed
• Realtime: chat
• Đa kênh: notification
• Object lớn: file upload
• Cận search: typeahead
• Tiền / nhất quán chặt: payment
• Streaming: analytics
• Thuật toán: rate limiter

Nếu trả lời được cả chín trong 45 phút mỗi cái, bạn trả lời được gần như mọi câu hỏi phỏng vấn.

Khi nào khung không áp dụng?

Hai tình huống.

Phỏng vấn coding bảng. Hình hoàn toàn khác - cấu trúc dữ liệu và thuật toán. Khung ở đây dành riêng cho system design.

Deep-dive đặc thù domain ("thiết kế tính năng X cụ thể của chúng tôi"). Người phỏng vấn mong bạn học domain của họ, không chạy khung chung. Hỏi nhiều câu clarify; dựa nền tảng từ chương 3.

Đi tiếp đâu từ đây?

Chương cuối: kết luận - năm bài học từ cả series và checklist bạn mang vào review kiến trúc hoặc phỏng vấn kế tiếp.