Bảo mậtTài liệu này chỉ dành cho Panel
Đề bài và đáp án tham chiếu trong tài liệu này không được chia sẻ trước cho ứng viên dưới bất kỳ hình thức nào — kể cả gợi ý domain hay độ khó. Chỉ phần Đề thi phát cho ứng viên (mục 02) mới được in ra và phát đúng vào giờ thi.
Vì sao cần một đề riêng, không dùng lại P05–P09 hay hai Worked Examples: nếu ứng viên đã thấy đề (dù ở Dojo tuần sau hay ở tài liệu học trước đó), bài Baseline không còn đo được khả năng suy luận dưới áp lực thời gian — chỉ đo trí nhớ. Đề này độc lập hoàn toàn với Problem Bank (Tài liệu 05) và Worked Examples (Tài liệu 10).
01Thông tin tổ chức thi
| Mục | Chi tiết |
|---|---|
| Thời lượng | 90 phút, cá nhân, im lặng, một phòng |
| Công cụ cho phép | Giấy A3, bút — không AI, không internet, không trao đổi |
| Sản phẩm nộp | Bản vẽ tay + 1 trang tóm tắt lập luận (viết tay hoặc đánh máy tại chỗ) |
| Ẩn danh | Ghi số báo danh, không ghi tên — xem quy trình tại Tài liệu 06 §08 |
| Chấm | Panel chấm blind theo Rubric (Tài liệu 02), dùng Standard Probing Questions (Tài liệu 06 §03) khi đọc bài |
02Đề thi phát cho ứng viên
— Phần này được in riêng, phát đúng giờ thi —
Bối cảnh nghiệp vụ
ISC vận hành cổng thu cước cho phép khách hàng thanh toán qua nhiều kênh: ví điện tử, cổng ngân hàng, đại lý thu hộ, và trừ thẳng qua tài khoản viễn thông. Mỗi kênh gửi xác nhận giao dịch về hệ thống trung tâm theo định dạng và độ trễ khác nhau. Bộ phận Tài chính phát hiện một số giao dịch bị đối soát sai: khách đã trả tiền nhưng hệ thống ghi chưa thanh toán (hoặc ngược lại), gây khiếu nại và sai lệch báo cáo doanh thu cuối tháng.
Yêu cầu: thiết kế hệ thống đối soát thanh toán đa kênh — nhận xác nhận giao dịch từ tất cả các kênh, đối chiếu với đơn thu cước gốc, phát hiện và xử lý sai lệch, tạo báo cáo đối soát cuối ngày và cuối tháng.
Ràng buộc định lượng
- ~4 kênh thanh toán hiện tại, dự kiến thêm 1–2 kênh mới trong năm tới
- ~800.000 giao dịch/ngày, phân bố không đều — dồn mạnh vào 3 ngày quanh hạn thanh toán cước hàng tháng (có thể gấp 15–20 lần ngày thường)
- Một số kênh xác nhận giao dịch ngay (dưới 1 giây), một số kênh chỉ gửi file đối soát theo lô mỗi 4 giờ hoặc cuối ngày
- Báo cáo đối soát cuối tháng phải hoàn tất trước 9:00 sáng ngày làm việc đầu tiên của tháng sau
- Sai lệch giữa các kênh (khách trả tiền nhưng chưa ghi nhận, hoặc ghi nhận trùng) phải được phát hiện trong vòng 24 giờ, không phải chờ tới cuối tháng
Nhiệm vụ
- Vẽ kiến trúc tổng thể (thành phần chính, luồng dữ liệu) — 30 phút
- Trình bày napkin math: ước lượng tải trung bình, tải đỉnh, và xác định thành phần nào chạm trần trước — 15 phút
- Nêu rõ cơ chế phát hiện sai lệch giữa các kênh có độ trễ khác nhau, và cách xử lý khi phát hiện — 20 phút
- Liệt kê tối thiểu 2 phương án cho một quyết định kiến trúc quan trọng trong bài, chọn 1 và giải thích vì sao loại phương án còn lại — 15 phút
- Viết 1 trang tóm tắt lập luận tổng thể — 10 phút
Lưu ý cho ứng viên (in kèm đề): đề bài cố ý không cung cấp đầy đủ thông tin. Nếu có giả định cần đưa ra để tiếp tục thiết kế, hãy ghi rõ giả định đó trong bài — panel đánh giá cả chất lượng giả định, không chỉ kết quả cuối.
03Napkin math tham chiếu chỉ panel
800.000 giao dịch/ngày (ngày thường)
→ 800.000 / 100.000 s ≈ 8 giao dịch/giây trung bình
Đỉnh cuối tháng: gấp 15–20 lần, dồn trong ~3 ngày
→ đỉnh tức thời có thể đạt 120–160 giao dịch/giây
(nếu phân bố đều trong 3 ngày; thực tế còn dồn hơn vào
vài giờ cao điểm trong mỗi ngày đó — ứng viên nhận ra
điều này là dấu hiệu tốt, dù đề không nói rõ con số giờ)
So với trần tham chiếu (xem Performance & Scale Handbook §02):
120–160 giao dịch/giây ghi vào Postgres — GẦN chạm trần
write đơn giản (vài nghìn/s) nhưng còn nhiều khoảng trống
→ đây KHÔNG phải bài toán cần sharding ngay, nhưng ứng viên
nên nhận ra đỉnh gấp 15–20 lần là con số phải thiết kế theo,
không phải theo trung bình.
Điểm mấu chốt của đề: bài toán khó nằm ở ĐỘ TRỄ LỆCH giữa
các kênh (một số tức thời, một số theo lô 4 giờ/cuối ngày),
không nằm ở thông lượng thô. Ứng viên chỉ tập trung "chịu tải"
mà bỏ qua bài toán đối soát lệch thời gian là thiếu trọng tâm.04Hai hướng tham chiếu chỉ panel
| Hướng | Mô tả | Đánh giá |
|---|---|---|
| A — Ledger trung tâm + đối soát lệch pha | Mỗi kênh ghi xác nhận vào một "ledger" trung gian ngay khi nhận được (bất kể tức thời hay theo lô). Một tiến trình đối soát chạy định kỳ (ví dụ mỗi giờ) so khớp ledger với đơn thu cước gốc theo transaction reference. Giao dịch chưa khớp sau một ngưỡng thời gian (ví dụ 24 giờ) được đánh dấu "chờ đối soát" và đẩy vào hàng đợi xử lý ngoại lệ cho nhân viên Tài chính. | Hướng hợp lý, xử lý đúng bản chất "lệch thời gian" của bài toán. Điểm cần thấy ở bài làm tốt: ứng viên phải nêu được transaction reference là khóa đối soát và bàn cách xử lý khi khóa đó không đồng nhất giữa các kênh (một số kênh trả về mã riêng của họ, cần bảng ánh xạ). |
| B — Đối soát real-time bằng event matching hai chiều | Mỗi giao dịch phát sinh một "chờ xác nhận" event; khi xác nhận từ kênh về, khớp ngay lập tức bằng stream processing, cảnh báo tức thời nếu không khớp trong X phút. | Về lý thuyết phát hiện sai lệch nhanh hơn hướng A, nhưng KHÔNG khả thi với các kênh chỉ gửi file theo lô 4 giờ/cuối ngày — real-time matching vô nghĩa khi một phía dữ liệu vốn đã trễ hàng giờ theo thiết kế của đối tác kênh. Ứng viên chọn B mà không xử lý mâu thuẫn này là dấu hiệu chưa đọc kỹ ràng buộc "một số kênh chỉ gửi file theo lô". |
Điều quan trọng nhất khi chấm bài này không phải "chọn A hay B". Một ứng viên chọn B nhưng chủ động nhận ra giới hạn của kênh theo lô và đề xuất SLA đối soát khác nhau theo từng kênh (real-time cho kênh tức thời, theo lô cho kênh chậm) vẫn thể hiện tư duy tốt hơn một ứng viên chọn A một cách máy móc không giải thích được vì sao.
05Ánh xạ nhiệm vụ → trụ rubric chỉ panel
| Nhiệm vụ trong đề | Chấm trụ nào |
|---|---|
| Kiến trúc tổng thể, luồng dữ liệu | Trụ 1 — Design & Modeling |
| Napkin math, xác định nút thắt | Trụ 2 — Quality Attributes |
| Cơ chế đối soát, xử lý dữ liệu lệch pha giữa các kênh | Trụ 3 — Data & Integration |
| So sánh phương án, chọn và giải thích lý do loại | Trụ 5 — Trade-off & Decision |
| Chất lượng trang tóm tắt — rõ ràng, có cấu trúc | Trụ 6 — Communication |
| Lựa chọn công nghệ đối soát/lưu trữ có lý do | Trụ 4 — Technology Judgment |
Áp dụng đúng ngưỡng gate như Rubric: bài đạt SA2 tổng thể phải đạt tối thiểu SA2 ở cả ba trụ 2, 3, 5.