Vòng system design 45 phút: một khung trả lời để không bị lạc đề

Vòng system design đáng sợ vì đề rất rộng ("thiết kế hệ thống rút gọn link", "thiết kế chat") và không có đáp án duy nhất. Người phỏng vấn chấm cách bạn dẫn dắt: hỏi đúng, chia nhỏ, cân nhắc đánh đổi. Dưới đây là một khung chia thời gian cho buổi 45 phút.

1. Làm rõ yêu cầu (5–8 phút)

Đừng vẽ ngay. Hỏi:

• Tính năng chính nào trong phạm vi buổi này? Cái gì để ngoài?
• Quy mô: bao nhiêu người dùng, bao nhiêu request mỗi giây, tỷ lệ đọc/ghi?
• Yêu cầu phi chức năng: độ trễ mong muốn, cần nhất quán ngay hay chấp nhận trễ vài giây, dữ liệu giữ bao lâu?

Viết các con số lên bảng. Ước lượng thô (100 triệu link, mỗi link khoảng 500 byte, nghĩa là cỡ 50 GB) là đủ để biết có cần chia nhỏ dữ liệu hay không.

2. API và mô hình dữ liệu (5–8 phút)

Liệt kê vài endpoint chính và các bảng hoặc collection. Đây là lúc thống nhất ngôn ngữ chung với người phỏng vấn.

3. Thiết kế tổng thể (10 phút)

Client → load balancer → service → database, thêm cache, hàng đợi, lưu trữ file khi cần. Giữ đơn giản trước, chạy được với quy mô nhỏ.

4. Đào sâu chỗ khó (15 phút)

Chọn một hai điểm nghẽn thật của đề và đi sâu:

• Đọc nhiều: cache ở đâu, invalidate thế nào.
• Ghi nhiều: chia shard theo khoá nào, tránh "điểm nóng".
• Thanh toán, chuyển tiền: idempotency, xử lý khi bên thứ ba timeout, đối soát.
• Real-time: WebSocket, fan-out tin nhắn cho nhóm lớn.

Với mỗi lựa chọn, nói rõ đánh đổi: "chọn cách này thì nhanh hơn nhưng dữ liệu có thể trễ vài giây, với feed thì chấp nhận được".

5. Lỗi và vận hành (5 phút)

Một service chết thì sao? Database chính chết thì sao? Theo dõi bằng chỉ số nào, cảnh báo khi nào? Phần này hay bị bỏ quên, nói được là điểm cộng lớn.

Lỗi hay gặp

• Nhảy vào microservices, Kafka, Kubernetes khi đề chỉ cần một database và một cache.
• Im lặng vẽ một mình. Hãy nói to và hỏi người phỏng vấn muốn đào sâu phần nào.
• Bám vào một chi tiết quá lâu rồi hết giờ trước khi có bức tranh tổng thể.

Đề system design khó nhất bạn từng gặp là gì? Kể ở dưới nhé.