Khung trả lời 45 phút

Vì sao cần khung

Một buổi system design thường kéo dài 45–60 phút, trong đó khoảng 5 phút giới thiệu và 5 phút cuối để bạn hỏi lại. Thời gian thật để thiết kế chỉ khoảng 35–40 phút, đúng với độ dài Grokking ghi cho phần system design.¹ (Tổng 45–60 phút và phần giới thiệu, hỏi lại là ước lượng của khoá học.) Không chia trước, bạn rất dễ dành 20 phút cho schema database rồi hết giờ trước khi chạm tới phần khó.

Khung dưới đây giúp bạn:

• Luôn có một thiết kế hoàn chỉnh, dù đơn giản, trước khi đào sâu. Grokking khuyên làm hai vòng: vòng đầu dồn khoảng 80% thời gian cho một thiết kế tốt nhất có thể, vòng sau để cải tiến.²
• Cho người phỏng vấn thấy bạn biết ưu tiên. Không nên bắt tay xây mà không có kế hoạch.³
• Có chỗ dựa khi bị hỏi bất ngờ: biết mình đang ở bước nào, còn bao nhiêu phút.

Sáu bước và thời gian

Thứ tự các bước bám theo cách Grokking trình bày mỗi bài thiết kế: yêu cầu chức năng và phi chức năng, ước lượng tài nguyên, khối xây dựng, API, thiết kế, rồi đánh giá theo yêu cầu phi chức năng.⁴ Grokking cũng liệt kê bốn hoạt động nên có trong buổi phỏng vấn: hỏi làm rõ, xử lý dữ liệu, bàn thành phần, bàn trade-off.⁵ Số phút cho từng bước là gợi ý của khoá học.

Bước 1: Yêu cầu

Mục tiêu là thu hẹp đề. "Thiết kế Instagram" quá rộng cho 45 phút. Bạn chọn 3–5 chức năng cốt lõi và thống nhất với người phỏng vấn. Grokking lấy ví dụ WhatsApp: bản thật có rất nhiều tính năng, nhưng chỉ cần vài chức năng cốt lõi để thể hiện khả năng giải quyết vấn đề; nếu người phỏng vấn phản đối thì điều chỉnh.¹

Yêu cầu chức năng viết theo dạng "Người dùng có thể...". Ví dụ với bài đặt vé: xem sự kiện, chọn ghế, giữ ghế trong 10 phút, thanh toán. Đây là nhóm yêu cầu khách hàng cần trực tiếp; nhóm cần gián tiếp (như hiệu năng không giảm khi tải tăng) là yêu cầu phi chức năng.⁵

Yêu cầu phi chức năng phải có số: p95 dưới 200 ms, sẵn sàng 99,9%, không bán trùng ghế, chấp nhận feed trễ vài giây. Những con số này quyết định thiết kế ở bước 4 và 5. Ví dụ sẵn sàng 99,9% cho phép khoảng 8,76 giờ ngừng mỗi năm, 99,99% chỉ còn khoảng 52,56 phút.⁶

Câu nên nói:

• "Em đề xuất tập trung vào ba chức năng này, phần thông báo và quản trị để ngoài phạm vi, anh thấy được không?"
• "Hệ thống này đọc nhiều hơn ghi đúng không? Khoảng bao nhiêu lần?"
• "Chỗ nào cần nhất quán mạnh, chỗ nào chấp nhận trễ?"

Hai câu cuối lấy từ danh sách câu hỏi về dữ liệu Grokking gợi ý: dữ liệu đọc nhiều hay ghi nhiều, cần nhất quán chặt hay nhất quán cuối cùng là đủ, dữ liệu lớn bao nhiêu và tăng nhanh thế nào.⁵

Bước 2: Ước lượng

Chỉ tính những số sẽ dùng. Thường là QPS đỉnh và dung lượng lưu trữ. Ghi rõ giả định để người phỏng vấn có thể chỉnh. Đừng đưa con số mà không có lý do đi kèm.³

DAU 1.000.000, mỗi người 20 lượt đọc, 2 lượt ghi mỗi ngày
Đọc TB  = 1.000.000 × 20 / 86.400 ≈ 231 req/s, đỉnh ×5 ≈ 1.160 req/s
Ghi TB  = 1.000.000 × 2 / 86.400  ≈ 23 req/s,  đỉnh ×5 ≈ 116 req/s
Lưu trữ = 2.000.000 bản ghi/ngày × 1 KB × 365 ≈ 730 GB/năm

Các đầu vào (20 lượt đọc, 2 lượt ghi, đỉnh ×5, 1 KB mỗi bản ghi) là giả định ví dụ của khoá học. Grokking cũng tính theo cách chia tổng request mỗi ngày cho 86.400 giây, và nhấn mạnh ở mức thiết kế chỉ cần ước lượng thô để có cận trên hợp lý.⁷

Kết luận từ số mới là phần quan trọng, vì mục đích của tính nhẩm là bỏ qua chi tiết vụn để tập trung vào điều ảnh hưởng thiết kế:⁸ "Đọc gấp 10 lần ghi, nên em sẽ có cache. 730 GB mỗi năm thì một Postgres còn chứa được 1–2 năm". Bảng con số tham khảo nằm ở Con số cần thuộc.

Bước 3: Thực thể và API

Liệt kê thực thể chính và quan hệ, chưa cần đủ cột. Sau đó viết các endpoint gắn với từng yêu cầu chức năng. Định nghĩa API phía người dùng ở mức cao giúp hiểu rõ dữ liệu và tương tác của hệ thống.⁵

POST /v1/events/{id}/holds      { seatIds }      -> holdId, expiresAt
POST /v1/holds/{id}/checkout    { paymentToken } -> bookingId
GET  /v1/events/{id}/seats                       -> danh sách ghế và trạng thái

Nói ngắn về cách xác thực (userId lấy từ token, không lấy từ body), phân trang bằng cursor, và idempotency key cho các thao tác tạo tiền hoặc đơn. Chi tiết và nguồn ở Thiết kế API và Mô hình dữ liệu.

Bước 4: Thiết kế tổng thể

Vẽ sơ đồ đơn giản nhất đáp ứng được từng yêu cầu chức năng. Đi lần lượt: "Yêu cầu một, request đi từ client qua API gateway tới service này, đọc bảng này". Sơ đồ thường vẽ thành phần là hộp, mũi tên cho biết ai nói chuyện với ai.⁹ Xong yêu cầu một mới sang yêu cầu hai.

Ở bước này chưa tối ưu. Một service và một database là đủ nếu nó đáp ứng yêu cầu. Bạn sẽ thêm cache, queue, shard ở bước 5 và 6 khi có lý do. Hệ thống thật cũng tiến hoá theo vòng lặp: bắt đầu đơn giản, khi xuất hiện nút thắt mới đổi thiết kế.²

Câu nên nói:

• "Em làm cho đúng trước, phần tải cao em sẽ quay lại ở bước sau."
• "Ở đây em dùng Postgres vì cần transaction cho việc giữ ghế."

Bước 5: Đào sâu

Chọn 2–3 vấn đề khó nhất của bài. Thường thuộc các nhóm: nhiều người tranh cùng tài nguyên, tải đỉnh đột biến, cập nhật realtime, dữ liệu quá lớn cho một node, lỗi giữa chừng. Bảy pattern trong Tổng quan pattern bao phủ phần lớn các vấn đề này.

Với mỗi vấn đề, trình bày theo thứ tự:

1. Cách đơn giản và vì sao nó chưa đủ.
2. Cách tốt hơn, cơ chế hoạt động.
3. Trade-off: tốn gì, phức tạp thêm ở đâu, khi nào nên chọn. Mỗi thành phần có ưu nhược riêng, mỗi lựa chọn có chi phí tiền và độ phức tạp khác nhau.¹⁰

Nếu người phỏng vấn muốn đào chỗ khác, đi theo họ. Họ đang chỉ cho bạn chỗ họ muốn chấm điểm.

Bước 6: Mở rộng 10 lần

Chỉ vào sơ đồ và nói thứ gì vỡ đầu tiên. Ví dụ: "Ở 10 lần tải, primary Postgres nhận khoảng 1.200 ghi mỗi giây, vẫn ổn. Nhưng bảng ghế của sự kiện lớn thành hot row, em sẽ chuyển việc giữ ghế sang Redis với TTL". Trả lời bằng nút thắt và con số, không liệt kê công nghệ. Câu hỏi "thiết kế thay đổi thế nào khi tải tăng một bậc" rất hay gặp, vì khi một khía cạnh tăng từ 10 lần trở lên, thiết kế cũ thường không còn đứng vững.¹¹ Bạn cũng có thể nói thẳng điểm yếu mình cố ý để lại, kèm kế hoạch giám sát tải.¹⁰

Đây là chỗ ba mức quy mô trong mỗi bài thiết kế phát huy tác dụng. Đọc thêm Hạ tầng theo quy mô.

Lỗi hay gặp

Phần lớn các lỗi dưới đây nằm trong danh sách "không nên làm" của Grokking: viết code, xây khi chưa có kế hoạch, làm im lặng, đưa số không có lý do, giả vờ biết.³

Nguồn trích dẫn

1. Grokking Modern System Design · ch.2 System Design Interviews · bài "What Is a System Design Interview?", mục "How do we tackle a design question?". ↩ ↩²

2. Grokking Modern System Design · ch.1 Introduction · mục "About this course" ("Iterative process"). ↩ ↩²

3. Grokking Modern System Design · ch.2 System Design Interviews · bài "How to Perform Well", mục "What not to do in an interview". ↩ ↩² ↩³

4. Grokking Modern System Design · ch.34 Design a URL Shortening Service (TinyURL) · mục "How will we design a URL shortening service?" và bài "Requirements of TinyURL's Design"; bài "Evaluation of TinyURL's Design". ↩

5. Grokking Modern System Design · ch.2 System Design Interviews · bài "How to Perform Well", các mục "Strategize, then divide and conquer", "Ask refining questions", "Handle data", "Discuss the components". ↩ ↩² ↩³ ↩⁴

6. Grokking Modern System Design · ch.4 Non-functional System Characteristics · bài "Availability", bảng "The Nines of Availability". ↩

7. Grokking Modern System Design · ch.5 Back-of-the-envelope Calculations · bài "Put Back-of-the-envelope Numbers in Perspective" (phần ước lượng số server ở mức thiết kế) và bài "Examples of Resource Estimation", mục "Number of servers required". ↩

8. Grokking Modern System Design · ch.5 Back-of-the-envelope Calculations · bài "Put Back-of-the-envelope Numbers in Perspective", mục "Why do we use back-of-the-envelope calculations?". ↩

9. Grokking Modern System Design · ch.2 System Design Interviews · bài "What Is a System Design Interview?", mục "Present the high-level design". ↩

10. Grokking Modern System Design · ch.2 System Design Interviews · bài "How to Perform Well", mục "Discuss trade-offs". ↩ ↩²

11. Grokking Modern System Design · ch.2 System Design Interviews · bài "What Is a System Design Interview?", mục "Possible questions for every SDI". ↩