Câu hỏi system design hay gặp: 8 đề phổ biến, khung 5 bước trả lời và đề thanh toán cho dân ngân hàng, fintech

Tóm tắt nhanh

• Câu hỏi system design là đề mở, kiểu "thiết kế dịch vụ rút gọn URL" hay "thiết kế hệ thống chat". Người chấm xem cách bạn lập luận, không chỉ xem kiến trúc cuối cùng.
• Các đề hay xuất hiện trong các nguồn tham khảo: URL shortener, rate limiter, chat, news feed, cache phân tán, hệ thống thông báo. Ngoài ra có thêm đề thanh toán nếu bạn ứng tuyển ngân hàng hoặc fintech.
• Khung gợi ý cho buổi 45 phút: làm rõ yêu cầu (5') → ước lượng (5') → thiết kế tổng quan (10') → đào sâu (15') → đánh đổi và cải tiến (10').
• Hai lỗi đáng tránh: lao vào vẽ kiến trúc khi chưa hỏi lại yêu cầu, và chỉ đưa một phương án mà không nói đánh đổi.
• Với đề thanh toán, hãy mở bằng câu: đây là bài toán đúng đắn và nhất quán dữ liệu, không phải bài toán chịu tải.

Nếu bạn vừa nhận lịch phỏng vấn có vòng thiết kế hệ thống, câu hỏi system design thường khiến người ta ngợp vì đề quá rộng. Bài này gom các đề hay gặp, một khung trả lời làm theo được, và phần riêng cho ai đi phỏng vấn ngân hàng hoặc fintech. Bài không nêu đề của một công ty cụ thể nào, vì không có nguồn công khai kiểm chứng được.

1. Câu hỏi system design là gì và ai bị hỏi?

Đây là hình thức phỏng vấn nhằm đánh giá năng lực thiết kế hệ thống. Bài của FPT Shop nói vòng này được các công ty công nghệ lớn như Google, Facebook, Amazon dùng để kiểm tra khả năng dựng kiến trúc cho phần mềm quy mô lớn. Chủ đề trọng tâm gồm caching, lưu trữ dữ liệu, nhân bản dữ liệu (replication), cân bằng tải, phân vùng dữ liệu, khả năng mở rộng và so sánh SQL với NoSQL.

Về người bị hỏi, một bài trên Viblo đặt bộ câu hỏi này trong ngữ cảnh tuyển Senior Backend Engineer. Tài liệu khóa học của DesignGurus thì cho biết kết quả vòng này ảnh hưởng trực tiếp đến việc xếp level và mức lương. Vì vậy nếu ứng tuyển vị trí senior, bạn nên coi đây là vòng cần chuẩn bị kỹ. Với các cấp thấp hơn, hãy hỏi HR vòng kỹ thuật gồm những phần nào.

Educative viết rằng vòng này không kiểm tra bạn xây được gì, mà kiểm tra bạn có lập luận được trên một bài toán mơ hồ, trình bày rõ ý tưởng và bảo vệ các đánh đổi hay không. Vì thế bạn nói to suy nghĩ của mình thì có lợi hơn là ngồi im vẽ cho đẹp.

2. Tám câu hỏi system design hay gặp

Các đề dưới đây tổng hợp từ Educative (30 đề chia 3 mức dễ, trung bình, khó), MockExperts, Viblo và một bài mẫu trên DEV Community. Cột bên phải là điều đề đó thường kiểm tra.

Đề cuối lấy từ danh sách câu hỏi Viblo. Bài này khuyên làm rõ ý nghĩa và độ lớn của dữ liệu, rồi trình bày giải pháp từ đơn giản đến phức tạp. Cách đi "đơn giản trước" cũng có thể áp dụng cho các đề khác.

3. Khung 5 bước trả lời trong 45 phút

Các nguồn chia bước hơi khác nhau. DesignGurus chia 7 bước (làm rõ yêu cầu, ước lượng, định nghĩa API, mô hình dữ liệu, thiết kế tổng quan, thiết kế chi tiết, xử lý điểm nghẽn). Educative gợi ý phân bổ thời gian cho buổi 45 phút theo 5 phần. Bài này dùng cách chia 5 phần của Educative:

1. Làm rõ yêu cầu (khoảng 5 phút). Hỏi ai dùng, dùng để làm gì, quy mô bao nhiêu, cái gì bắt buộc và cái gì để sau.
2. Ước lượng (khoảng 5 phút). Đổi "phải mở rộng được" thành số: request mỗi giây, dung lượng lưu trữ.
3. Thiết kế tổng quan (khoảng 10 phút). Vẽ vài khối chính (DesignGurus gợi ý 5–6 khối), có thể kèm API và mô hình dữ liệu.
4. Đào sâu (khoảng 15 phút). Đây là phần được dành nhiều thời gian nhất. Chọn vài thành phần khó nhất để mổ xẻ.
5. Đánh đổi và cải tiến (khoảng 10 phút). Nêu các đánh đổi, điểm nghẽn và hướng cải tiến.

DesignGurus lưu ý buổi phỏng vấn thường chỉ kéo dài 35–40 phút. Vì vậy hãy hỏi ngay từ đầu buổi: "Mình có khoảng bao nhiêu thời gian cho phần này?". Sau đó chia lại các bước cho khớp.

4. Ví dụ làm mẫu: ước lượng cho URL shortener

Phần ước lượng khiến nhiều người bí nhất, nên xem một ví dụ. Tài liệu ByteByteGo giả định 100 triệu URL tạo mới mỗi ngày. Chia cho 86.400 giây thì ra khoảng 1.160 lượt ghi mỗi giây. Với tỉ lệ đọc/ghi 10:1, lượt đọc là khoảng 11.600 mỗi giây.

Về lưu trữ, 10 năm là 365 tỉ bản ghi, mỗi bản ghi khoảng 100 byte, tức khoảng 36,5 TB. Mã dài 7 ký tự trong bảng 62 ký tự cho khoảng 3,5 nghìn tỉ tổ hợp (62^7), nhiều hơn hẳn mức 365 tỉ cần dùng.

Còn hai điểm để đào sâu. Một là redirect 301 (trình duyệt cache nên giảm tải server, nhưng khó theo dõi lượt click hơn) hay 302 (theo dõi click tốt hơn nhưng server chịu thêm tải). Hai là sinh mã bằng hash cộng xử lý trùng, hay đổi ID sang base 62. Hash cộng xử lý trùng cho mã độ dài cố định, phải xử lý va chạm nhưng không phụ thuộc bộ sinh ID. Base 62 không trùng mã nhưng cần bộ sinh ID duy nhất, và địa chỉ kế tiếp có thể đoán được.

Con số giả định khác nhau giữa các nguồn. MockExperts dùng tỉ lệ đọc/ghi 100:1 cho cùng đề này. Vì vậy đừng học thuộc số. Hãy hỏi người phỏng vấn con số họ muốn dùng rồi tính tiếp từ đó.

5. Câu hỏi system design cho phỏng vấn ngân hàng và fintech

Với phỏng vấn ngân hàng hoặc fintech, đề thanh toán, ví điện tử, chuyển tiền là hướng chuẩn bị hợp lý. Educative xếp cổng thanh toán kiểu Stripe vào nhóm đề khó. Cách đóng khung theo một bài mẫu trên DEV Community: đây là bài toán đúng đắn và nhất quán, không phải bài toán chịu tải.

Bài mẫu đó ước lượng khoảng 10 triệu giao dịch mỗi ngày, tức khoảng 115 giao dịch mỗi giây, đỉnh gấp 10 lần vào dịp khuyến mãi, khoảng 1.150 mỗi giây, và hơn 20 triệu bút toán sổ cái mỗi ngày. Mức tải này khá vừa phải. Điều khó là không được sai tiền. Ba ý bạn nên nói được:

• Idempotency: client gửi một khóa duy nhất theo từng yêu cầu. Server lưu khóa cùng kết quả trong cùng một thao tác với lệnh trừ tiền. Gửi lại với cùng tham số thì trả đúng kết quả cũ. Cùng khóa mà khác nội dung thì từ chối bằng lỗi 409 Conflict.
• Sổ cái ghi kép: mỗi giao dịch tạo bút toán nợ và có sao cho tổng nợ bằng tổng có. Sổ chỉ ghi thêm, sửa sai bằng bút toán đảo, số dư là giá trị tính ra từ sổ.
• Đối soát: job định kỳ so sổ nội bộ với file quyết toán của đối tác theo mã giao dịch, số tiền và ngày. Bản ghi nào không khớp thì đánh dấu để xử lý, sửa bằng bút toán đảo.

Người phỏng vấn có thể hỏi tiếp những tình huống như: khách bấm Thanh toán hai lần thì trừ mấy lần (một lần, nhờ khóa idempotency), webhook về hai lần thì sao (khử trùng theo mã giao dịch của đối tác, có ràng buộc unique), hệ thống mình ghi thành công nhưng đối tác báo thất bại thì sao (đối soát phát hiện rồi đảo bút toán).

6. Năm lỗi hay làm mất điểm

DesignGurus nêu các lỗi sau:

1. Bỏ qua bước làm rõ yêu cầu, lao vào kiến trúc, nên thiết kế rời rạc.
2. Chỉ đưa một phương án, không nói đánh đổi.
3. Sa vào chi tiết cài đặt thay vì kiến trúc.
4. Không nghĩ tới lúc hệ thống hỏng hay điểm nghẽn mở rộng.
5. Quản lý thời gian kém giữa các bước.

Bài Viblo thì cảnh báo riêng về thiết kế kiến trúc: hãy cẩn thận khi nhắc tới Domain-Driven Design, vì bạn cần nắm rõ nghiệp vụ và cách mô hình hóa nghiệp vụ mình dùng. Nếu bạn nhắc một thuật ngữ, hãy sẵn sàng giải thích vì sao áp dụng nó vào đề này.

Bạn nên làm gì trước buổi phỏng vấn

• Chọn 4–5 đề trong bảng ở mục 2 và tự làm từng đề theo khung 5 bước, bấm giờ cho đủ 45 phút. Với ngân hàng và fintech, ưu tiên đề thanh toán.
• Soạn sẵn danh sách câu hỏi làm rõ yêu cầu dùng cho mọi đề: ai dùng, quy mô, đọc nhiều hay ghi nhiều, cần nhất quán mạnh hay chấp nhận nhất quán cuối cùng, độ trễ chấp nhận được.
• Với mỗi lựa chọn kỹ thuật, tập nói một câu đánh đổi. Ví dụ: "Em chọn 302 vì cần đếm click, đổi lại server chịu nhiều request hơn".
• Tập vẽ khối bằng tay hoặc trên công cụ vẽ trực tuyến để không mất thời gian lúc phỏng vấn.
• Chuẩn bị 2–3 câu hỏi hỏi lại công ty. Ví dụ: hệ thống team đang vận hành có quy mô cỡ nào, team xử lý sự cố ra sao, quyết định kiến trúc được đưa ra thế nào. Câu trả lời giúp bạn hình dung cách team làm việc.

Câu hỏi thường gặp

Câu hỏi system design có đáp án đúng duy nhất không?

Các nguồn tham khảo không coi đây là bài có một kiến trúc đúng cần học thuộc. Educative viết rằng vòng này không kiểm tra bạn xây được gì, mà kiểm tra bạn có lập luận được trên một bài toán mơ hồ, trình bày rõ ý tưởng và bảo vệ các đánh đổi hay không. Vì vậy hãy nêu rõ yêu cầu, lý do chọn và đánh đổi cho từng quyết định.

Phỏng vấn system design khác gì so với các vòng khác?

Điểm khác nằm ở cách chấm: theo Educative, người phỏng vấn nhìn cách bạn xử lý sự mơ hồ, trình bày đánh đổi và ra quyết định, chứ không nhìn kiến trúc học thuộc. Theo khung của DesignGurus, bước đầu tiên là tự hỏi để làm rõ yêu cầu, rồi mới ước lượng và thiết kế. Educative cũng dành phần thời gian lớn nhất cho việc đào sâu một số thành phần, thay vì lướt qua toàn bộ hệ thống.

Phỏng vấn ngân hàng có hỏi system design không?

Bài này không tìm được nguồn công khai nói ngân hàng cụ thể nào hỏi gì, nên không khẳng định. Cách an toàn là hỏi HR vòng kỹ thuật gồm những phần nào. Với vị trí backend trong ngân hàng hoặc fintech, nên chuẩn bị đề thanh toán với idempotency, sổ cái và đối soát.

Quên mất con số ước lượng thì xử lý thế nào?

Nói rõ giả định rồi tính tiếp. Ví dụ "giả sử 100 triệu yêu cầu mỗi ngày, chia 86.400 giây thì được khoảng 1.160 mỗi giây". Điều người phỏng vấn muốn thấy là bạn biết đổi yêu cầu thành con số và dùng con số đó để quyết định thiết kế, không phải thuộc lòng số liệu.

---

Bài do hệ thống AI của Drama Công Ty tổng hợp từ các nguồn bên dưới và tự kiểm tra số liệu. Thấy sai, bạn bình luận hoặc báo cáo bài để ban biên tập sửa.

Nguồn

• System Design Interview Guide — DesignGurus
• System Design Interview Guide 2026: Framework, Concepts & Questions — DesignGurus
• System Design Interview Questions 2026 — Educative
• Design A URL Shortener — ByteByteGo
• Top 5 System Design Interview Questions 2026 (With Full Answers) — MockExperts
• Design a Payment System: the system design interview walkthrough — DEV Community
• Top 10 câu hỏi phỏng vấn về System Design và Microservices — Viblo
• System Design Interview là gì? 7 bước chuẩn bị cho dân IT tự tin chinh phục phỏng vấn — FPT Shop