00Cách dùng Problem Bank
Quy trình một tuần
- Thứ 2: phát đề — chỉ phần Bối cảnh và Ràng buộc. Không phát trọng tâm chấm và đáp án tham chiếu.
- Trong tuần: 2–3 giờ, cá nhân hoặc cặp, vẽ tay trên A3, không AI, không internet.
- Thứ 6: 2 người trình bày 15 phút, panel phản biện, 20 phút rút nguyên tắc chung.
- Sau buổi: người trình bày viết 1 ADR + 1 trang đối chiếu AI review.
Panel chuẩn bị 30 phút trước buổi
- Đọc phần Đáp án tham chiếu và Câu hỏi phản biện của đề tuần đó
- Đọc bộ Standard Probing Questions trong Facilitation Guide
- Không cần biết đáp án đúng — cần biết câu hỏi đúng
Đáp án tham chiếu không phải đáp án đúng. Đó là hai hướng hợp lý để panel đối chiếu. Một thiết kế khác hai hướng này vẫn có thể tốt hơn — điều quyết định là chất lượng lập luận, không phải sự trùng khớp.
MAPBản đồ 12 đề
| Mã | Tên | Tháng | Trụ / mức | Mục tiêu học tập | Kỹ năng rèn |
|---|---|---|---|---|---|
| P01 | Bounded context cho B2B Order | 1 | 1 · SA1 | Đặt ranh giới theo nghiệp vụ và gắn mức phân rã với năng lực team. | Phân rã, đặt ranh giới |
| P02 | API contract giữa 3 hệ thống | 1 | 3, 6 · SA1 | Xác định source of truth và thiết kế contract chịu được release lệch nhịp. | Contract, versioning, đàm phán |
| P03 | Tách service đầu tiên khỏi monolith | 1 | 1, 5 · SA1 | Chọn thứ tự tách có kiểm soát, nhận diện rủi ro migration và không tách theo phong trào. | Thứ tự tách, rủi ro |
| P04 | Vẽ C4 hệ thống thật của team mình | 1 | 1, 6 · SA1 | Chuyển hệ thống thật thành mô hình đủ rõ để team cùng hiểu và phản biện. | Mô hình hoá thực tế |
| P05 | Campaign engine — đỉnh 50× | 2 | 2, 3 · SA2 | Thiết kế theo peak thay vì average và bảo vệ tính đúng khi retry hoặc gửi trùng. | Napkin math, idempotency |
| P06 | Customer 360 — nhất quán 4 nguồn | 2 | 3, 2 · SA2 | Chọn mức nhất quán phù hợp và giải thích độ trễ giữa các nguồn dữ liệu. | Eventual consistency, CDC |
| P07 | Dependency ngoài chết 2 giờ | 2 | 2, 5 · SA2 | Thiết kế degraded mode và giới hạn tác động khi dependency lỗi kéo dài. | Resilience patterns |
| P08 | Curveball — ngân sách giảm 50% | 2 | 5, 6 · SA2 | Thay đổi quyết định khi ràng buộc đổi và nói rõ điều gì được hy sinh. | Ra quyết định tại chỗ |
| P09 | B2B CRM — dữ liệu lệch nặng | 3 | 2, 3 · SA2 | Nhận diện phân phối lệch và tránh chọn partition key tạo hot partition. | Hot partition, tail latency |
| P10 | Build vs Buy — CDP | 3 | 4, 5 · SA2 | So sánh tổng chi phí sở hữu, lock-in, năng lực team và khả năng đảo ngược. | TCO, lock-in |
| P11 | Tích hợp LLM vào luồng nghiệp vụ | 3 | 4, 3 · SA2 | Đặt ranh giới sử dụng AI trong ràng buộc dữ liệu, chi phí, độ tin cậy và kiểm soát đầu ra. | Kiến trúc AI có ràng buộc dữ liệu |
| P12 | Capstone — kiến trúc lại hệ thống thật | 3 | 1–6 · SA2 | Tổng hợp các trụ để bảo vệ một lộ trình kiến trúc trước stakeholder thật. | Tổng hợp, bảo vệ trước stakeholder |
P01 · Tháng 1 · Trụ 1Bounded context cho hệ thống Order B2B
Bối cảnh nghiệp vụ
Một hệ thống quản lý đơn hàng doanh nghiệp hiện là một ứng dụng duy nhất, xử lý toàn bộ: báo giá, hợp đồng, đơn hàng, giao hàng, đối soát công nợ, và hồ sơ khách hàng. Đội phát triển 12 người, mỗi lần release phải deploy toàn bộ và mất 4 giờ regression.
Ràng buộc định lượng (phát cho người giải)
- Khoảng 300 người dùng nội bộ, 2.000 đơn hàng/ngày
- Bộ phận kinh doanh và bộ phận kế toán yêu cầu tính năng thay đổi với nhịp rất khác nhau
- Một team 12 người, không tăng thêm người trong 12 tháng tới
Thông tin cố tình bỏ trống test chủ động hỏi
Không cho biết chu kỳ thay đổi của từng bộ phận, không cho biết bộ phận nào đang chặn tiến độ nhiều nhất, không cho biết dữ liệu nào đang được chia sẻ giữa các phần. Người giải phải hỏi.
Trọng tâm chấm
- Đường cắt đặt theo nghiệp vụ hay theo bảng dữ liệu — cắt theo bảng là dấu hiệu SA0–SA1
- Có nhận ra khái niệm "khách hàng" mang nghĩa khác nhau ở kinh doanh và kế toán không
- Có đề xuất modular monolith trước khi nhảy sang microservices không
- Có gắn ranh giới với năng lực đội ngũ 12 người không
Đáp án tham chiếu cho panel
| Hướng | Nội dung & đánh đổi |
|---|---|
| Hướng A — modular monolith | Giữ một deployable, tách module theo context với ranh giới rõ trong code, mỗi module có schema riêng, giao tiếp qua interface nội bộ. Rẻ, phù hợp 12 người, giải quyết được vấn đề nhịp release nếu bổ sung test theo module. Đánh đổi: vẫn deploy chung. |
| Hướng B — tách 2 service | Tách phần Tài chính/Công nợ ra riêng vì nhịp thay đổi và yêu cầu tuân thủ khác hẳn. Giữ phần còn lại. Đánh đổi: cần integration contract, cần xử lý nhất quán giữa đơn hàng và công nợ, tăng chi phí vận hành. |
| Cảnh báo | Thiết kế tách 6–7 service cho một team 12 người là dấu hiệu chưa gắn kiến trúc với năng lực tổ chức — Conway's Law ngược. |
Câu hỏi phản biện dành riêng cho đề này
- "Khách hàng" trong module kinh doanh và trong module kế toán có phải cùng một thứ không?
- Nếu chỉ được tách đúng một phần, anh tách phần nào? Vì sao phần đó?
- 12 người vận hành bao nhiêu service là hợp lý? Con số của anh dựa trên gì?
P02 · Tháng 1 · Trụ 3, 6API contract giữa ba hệ thống khác chủ sở hữu
Bối cảnh nghiệp vụ
Ba hệ thống thuộc ba team khác nhau cần trao đổi thông tin trạng thái thuê bao: hệ thống bán hàng, hệ thống kỹ thuật, và hệ thống chăm sóc khách hàng. Hiện mỗi cặp tự gọi API trực tiếp của nhau, tổng cộng 6 điểm tích hợp, mỗi lần một bên đổi field là hai bên kia hỏng.
Ràng buộc định lượng (phát cho người giải)
- Mỗi hệ thống có lịch release riêng, không thể deploy đồng thời
- Khoảng 50.000 lượt thay đổi trạng thái/ngày
- Yêu cầu: một bên đổi không được làm hỏng bên kia
Thông tin cố tình bỏ trống test chủ động hỏi
Không cho biết bên nào là nguồn sự thật của trạng thái thuê bao, không cho biết độ trễ chấp nhận được, không cho biết có yêu cầu lịch sử thay đổi không.
Trọng tâm chấm
- Có hỏi ai là nguồn sự thật (source of truth) trước khi vẽ không — đây là câu hỏi quan trọng nhất
- Có phân biệt được backward compatible và breaking change không
- Có đề xuất cơ chế versioning cụ thể không hay chỉ nói chung chung
- Có xử lý được vấn đề release lệch nhịp không
Đáp án tham chiếu cho panel
| Hướng | Nội dung & đánh đổi |
|---|---|
| Hướng A — contract-first, point-to-point | Giữ gọi trực tiếp nhưng chuẩn hoá: mỗi API có schema versioned, quy tắc chỉ thêm field không xoá, consumer-driven contract test trong CI. Rẻ, không thêm hạ tầng. Đánh đổi: số điểm tích hợp vẫn tăng theo bình phương số hệ thống. |
| Hướng B — event-driven qua broker | Hệ thống nguồn phát event thay đổi trạng thái, hai bên còn lại subscribe. Giảm coupling thời gian, có sẵn lịch sử. Đánh đổi: phải xử lý ordering và idempotency, cần vận hành broker, debug khó hơn. |
| Điểm chốt | Cả hai hướng đều sai nếu chưa xác định được nguồn sự thật. Không có owner rõ ràng thì không có contract nào cứu được. |
Câu hỏi phản biện dành riêng cho đề này
- Ai là nguồn sự thật của trạng thái thuê bao? Nếu hai hệ thống nói khác nhau thì tin ai?
- Bên A đổi schema hôm nay, bên B deploy sau 3 tuần — điều gì xảy ra trong 3 tuần đó?
- Thêm hệ thống thứ tư thì thiết kế của anh phải sửa bao nhiêu chỗ?
P03 · Tháng 1 · Trụ 1, 5Tách service đầu tiên khỏi monolith
Bối cảnh nghiệp vụ
Một hệ thống nội bộ chạy 6 năm, khoảng 400.000 dòng code, một database duy nhất 180 bảng. Hệ thống đang chạy 24/7, không được phép downtime quá 15 phút. Ban lãnh đạo đồng ý đầu tư tách dần, nhưng yêu cầu thấy kết quả trong 3 tháng đầu.
Ràng buộc định lượng (phát cho người giải)
- Không được downtime quá 15 phút cho mỗi lần chuyển đổi
- Team 8 người, phải tiếp tục làm feature song song
- 3 tháng phải có kết quả chứng minh được
Thông tin cố tình bỏ trống test chủ động hỏi
Không cho biết phần nào thay đổi nhiều nhất, phần nào ít phụ thuộc nhất, phần nào đang gây sự cố nhiều nhất. Người giải phải hỏi để chọn được ứng viên tách đầu tiên.
Trọng tâm chấm
- Tiêu chí chọn phần tách đầu tiên — chọn theo "dễ" hay theo "giá trị"
- Có nhắc tới strangler fig hoặc cơ chế chuyển dần không
- Có xử lý bài toán dữ liệu dùng chung không (thường là chỗ bị bỏ qua)
- Có kế hoạch rollback không
Đáp án tham chiếu cho panel
| Hướng | Nội dung & đánh đổi |
|---|---|
| Hướng A — tách phần rìa, ít phụ thuộc | Chọn module đọc nhiều ghi ít, ít liên quan dữ liệu lõi (ví dụ báo cáo, thông báo). Rủi ro thấp, chứng minh được quy trình tách. Đánh đổi: giá trị nghiệp vụ thấp, dễ bị đánh giá là không đáng đầu tư tiếp. |
| Hướng B — tách phần đau nhất | Chọn module thay đổi nhiều nhất và gây sự cố nhiều nhất. Giá trị cao, thuyết phục được lãnh đạo đầu tư tiếp. Đánh đổi: rủi ro cao ở lần đầu, nếu hỏng thì cả chương trình bị dừng. |
| Chi tiết panel nên hỏi kỹ | Dữ liệu: tách service nhưng vẫn dùng chung database là nửa vời — phải hỏi kế hoạch tách schema, cơ chế đồng bộ trong giai đoạn chuyển tiếp, và cách xử lý transaction xuyên ranh giới. |
Câu hỏi phản biện dành riêng cho đề này
- Nếu tách xong mà vẫn dùng chung database thì anh đã đạt được gì?
- Trong 3 tháng, giữa "chứng minh quy trình an toàn" và "giải quyết điểm đau lớn nhất", anh chọn gì và vì sao?
- Lần chuyển đổi thất bại lúc 2 giờ sáng — kế hoạch quay lui của anh là gì?
P04 · Tháng 1 · Trụ 1, 6Vẽ C4 cho hệ thống thật mà team mình đang làm
Bối cảnh nghiệp vụ
Không phải bài giả lập. Mỗi người vẽ C4 Level 1 và Level 2 cho chính hệ thống mình đang phát triển, kèm một trang mô tả ba điểm yếu kiến trúc mà mình nhìn thấy.
Ràng buộc định lượng (phát cho người giải)
- Vẽ tay, không dùng tài liệu có sẵn của dự án
- Level 1: hệ thống trong bối cảnh — ai dùng, nói chuyện với hệ thống nào
- Level 2: các thành phần bên trong và luồng dữ liệu chính
- Kèm 3 điểm yếu kiến trúc và hệ quả nếu không xử lý
Thông tin cố tình bỏ trống test chủ động hỏi
Không có — đây là bài kiểm tra hiểu biết về hệ thống của chính mình. Kết quả thường gây bất ngờ: nhiều người không vẽ được hệ thống mình làm hàng ngày.
Trọng tâm chấm
- Vẽ được từ trí nhớ hay phải tra tài liệu
- Có phân biệt được Level 1 và Level 2 không, hay trộn lẫn mọi thứ vào một hình
- Ba điểm yếu nêu ra là điểm yếu kiến trúc hay chỉ là nợ code
- Có gắn điểm yếu với hệ quả nghiệp vụ không
Đáp án tham chiếu cho panel
| Hướng | Nội dung & đánh đổi |
|---|---|
| Không có đáp án tham chiếu | Panel so sánh bản vẽ của các thành viên cùng team với nhau. Nếu hai người cùng team vẽ ra hai hệ thống khác nhau — đó là phát hiện quan trọng nhất của buổi này, và là dữ liệu thật về mức độ chia sẻ hiểu biết kiến trúc trong team. |
| Kết quả phụ có giá trị | Bộ bản vẽ này trở thành tài sản của phòng: đầu vào cho Knowledge Base và cho onboarding người mới. |
Câu hỏi phản biện dành riêng cho đề này
- Ai là người dùng thật của hệ thống này? Anh đã nói chuyện với họ lần gần nhất khi nào?
- Thành phần nào trong hình sẽ phải sửa nếu yêu cầu nghiệp vụ lớn nhất năm sau xảy ra?
- Ba điểm yếu anh nêu, cái nào sẽ gây sự cố production trước?
P05 · Tháng 2 · Trụ 2, 3Campaign engine — 5 triệu thông báo/ngày, đỉnh dồn 30 phút
Bối cảnh nghiệp vụ
Bộ phận marketing cần hệ thống gửi thông báo cá nhân hoá tới khách hàng qua nhiều kênh (SMS, push, email, Zalo OA). Marketing tự cấu hình chiến dịch, chọn tệp khách hàng và thời điểm gửi. Hệ thống phải tracking mở/click và tuyệt đối không gửi trùng.
Ràng buộc định lượng (phát cho người giải)
- 5 triệu thông báo/ngày, khoảng 60% dồn trong 30 phút của khung giờ vàng
- Không được gửi trùng cho cùng một khách hàng trong cùng chiến dịch
- Tracking mở/click phải có trong báo cáo trong vòng 15 phút
- Nhà cung cấp SMS giới hạn 500 tin/giây và đôi khi trả lỗi tạm thời
Thông tin cố tình bỏ trống test chủ động hỏi
Không cho biết mức chấp nhận được của việc gửi thiếu, không cho biết có yêu cầu gửi đúng giờ tuyệt đối hay được phép trễ, không cho biết ngân sách hạ tầng.
Trọng tâm chấm
- Có làm napkin math trước khi vẽ không — đây là bài chấm nặng nhất về điểm này
- Có nhận ra nút thắt nằm ở tầng ghi và ở giới hạn nhà cung cấp, không phải ở message broker không
- Cơ chế chống gửi trùng có chịu được retry không (idempotency key)
- Có xử lý backpressure khi nhà cung cấp chậm không
Đáp án tham chiếu cho panel
| Hướng | Nội dung & đánh đổi |
|---|---|
| Napkin math đúng | Trung bình ≈ 58/s. Đỉnh: 3 triệu / 1.800 s ≈ 1.700/s — gấp 34× trung bình. Nhà cung cấp SMS chỉ nhận 500/s → nút thắt cứng nằm ngoài hệ thống. Nhận ra điều này là chìa khoá của cả bài. |
| Hướng A — hàng đợi + rate limiter | Sinh danh sách gửi trước, đẩy vào queue, worker gửi theo tốc độ nhà cung cấp cho phép. Đỉnh được hấp thụ bằng hàng đợi, chấp nhận thời gian gửi kéo dài. Cần idempotency key = hash(campaign_id + customer_id + kênh). Đánh đổi: không gửi đúng giờ tuyệt đối. |
| Hướng B — tiền xử lý theo lô | Chuẩn bị sẵn toàn bộ nội dung trước giờ gửi, lưu dạng đã cá nhân hoá, giờ G chỉ việc bắn. Giảm tải tính toán lúc đỉnh. Đánh đổi: dữ liệu có thể cũ tại thời điểm gửi, tốn dung lượng lưu tạm. |
| Tracking | Sự kiện mở/click là luồng ghi lớn hơn luồng gửi (mỗi thông báo có thể sinh nhiều sự kiện). Người giải bỏ qua điều này là thiếu sót quan trọng — cần tách luồng ghi sự kiện và tổng hợp theo lô. |
Câu hỏi phản biện dành riêng cho đề này
- Đỉnh gấp bao nhiêu lần trung bình? Con số đó lấy từ đâu?
- Nhà cung cấp chỉ nhận 500/s trong khi anh cần 1.700/s — hệ thống của anh phản ứng thế nào?
- Worker chết giữa chừng sau khi đã gửi nhưng chưa kịp ghi nhận — khách hàng có bị gửi lại không?
- Luồng ghi sự kiện tracking lớn hơn hay nhỏ hơn luồng gửi?
P06 · Tháng 2 · Trụ 3, 2Customer 360 — hợp nhất hồ sơ từ bốn nguồn
Bối cảnh nghiệp vụ
Cần xây hồ sơ khách hàng hợp nhất từ bốn hệ thống nguồn: hệ thống thuê bao, hệ thống thanh toán, hệ thống chăm sóc khách hàng, và dữ liệu tương tác marketing. Bộ phận marketing cần truy vấn phân khúc (ví dụ: khách hàng dùng gói X, có khiếu nại trong 30 ngày, chưa mở email 3 chiến dịch gần nhất) và nhận kết quả trong vài giây.
Ràng buộc định lượng (phát cho người giải)
- Khoảng 8 triệu khách hàng
- Bốn nguồn có định danh khách hàng khác nhau, một phần trùng khớp bằng số điện thoại
- Truy vấn phân khúc phải trả kết quả dưới 5 giây
- Dữ liệu cập nhật gần thời gian thực — chấp nhận trễ vài phút
Thông tin cố tình bỏ trống test chủ động hỏi
Không cho biết tỉ lệ dữ liệu khớp được giữa các nguồn, không cho biết nguồn nào ưu tiên khi mâu thuẫn, không cho biết có yêu cầu xoá dữ liệu theo quy định không.
Trọng tâm chấm
- Có tách mô hình ghi và mô hình đọc không — truy vấn phân khúc và cập nhật realtime là hai bài toán khác nhau
- Có xử lý bài toán khớp định danh (identity resolution) không, hay giả định là có sẵn khoá chung
- Có nêu quy tắc ưu tiên khi bốn nguồn nói khác nhau không
- Có nhận ra đây là bài toán eventual consistency và nói rõ mức trễ chấp nhận được không
Đáp án tham chiếu cho panel
| Hướng | Nội dung & đánh đổi |
|---|---|
| Hướng A — CDC + kho hợp nhất | Bắt thay đổi từ bốn nguồn qua CDC, đẩy vào luồng sự kiện, xây hồ sơ hợp nhất trong kho dữ liệu tối ưu cho đọc. Truy vấn phân khúc chạy trên kho này. Đánh đổi: trễ vài phút, cần vận hành pipeline, cần xử lý sự kiện đến sai thứ tự. |
| Hướng B — truy vấn liên nguồn | Không sao chép dữ liệu, truy vấn trực tiếp bốn nguồn khi cần. Luôn mới nhất. Đánh đổi: không đạt được yêu cầu 5 giây trên 8 triệu bản ghi với join xuyên hệ thống — hướng này thực tế không khả thi, nhưng cần cho người giải tự nhận ra thay vì được nói trước. |
| Điểm phân loại SA1 vs SA2 | SA1 sẽ vẽ ngay kho dữ liệu. SA2 sẽ dừng lại ở bài toán khớp định danh trước: nếu 30% khách hàng không khớp được giữa các nguồn thì hồ sơ hợp nhất sai, và không kiến trúc nào cứu được. |
Câu hỏi phản biện dành riêng cho đề này
- Bốn nguồn nói khác nhau về địa chỉ khách hàng — anh tin nguồn nào? Quy tắc đó ai đặt?
- Tỉ lệ khớp định danh giữa các nguồn là bao nhiêu? Nếu chỉ 70% thì sao?
- Một sự kiện từ nguồn A đến sau sự kiện cũ hơn từ nguồn B — hồ sơ hợp nhất ra kết quả gì?
- Marketing chạy một truy vấn phân khúc nặng lúc 9 giờ sáng — nó ảnh hưởng gì tới hệ thống nguồn?
P07 · Tháng 2 · Trụ 2, 5Dependency bên ngoài chết hai giờ
Bối cảnh nghiệp vụ
Hệ thống đăng ký dịch vụ của bạn phụ thuộc vào một API xác thực thông tin khách hàng do đơn vị bên ngoài cung cấp. API này nằm ngoài tầm kiểm soát, SLA cam kết 99% (tức khoảng 7 giờ downtime/tháng). Hôm qua nó chết 2 giờ và toàn bộ luồng đăng ký của bạn dừng, đồng thời hệ thống chăm sóc khách hàng cũng chậm theo dù không liên quan.
Ràng buộc định lượng (phát cho người giải)
- API bên ngoài: SLA 99%, thời gian phản hồi bình thường 300 ms, khi quá tải lên 30 giây
- Luồng đăng ký: 20.000 lượt/ngày, cao điểm 8–10 giờ sáng
- Yêu cầu nghiệp vụ: không được đăng ký cho khách hàng chưa xác thực
Thông tin cố tình bỏ trống test chủ động hỏi
Không cho biết xác thực bắt buộc phải xong trước khi tạo đơn hay có thể xác thực sau, không cho biết chi phí của một đơn sai, không cho biết hệ thống chăm sóc khách hàng dùng chung tài nguyên gì.
Trọng tâm chấm
- Có giải thích được vì sao hệ thống chăm sóc khách hàng cũng chậm không (connection pool dùng chung — đây là điểm chốt)
- Có nêu đủ bộ timeout + circuit breaker + bulkhead không, hay chỉ nói "thêm retry"
- Có đặt lại câu hỏi nghiệp vụ: xác thực có nhất thiết phải đồng bộ không
- Có phân biệt degrade (giảm chất lượng) và fail (dừng hẳn) không
Đáp án tham chiếu cho panel
| Hướng | Nội dung & đánh đổi |
|---|---|
| Chẩn đoán đúng | Nguyên nhân hệ thống chăm sóc khách hàng chậm theo là cascading failure qua tài nguyên dùng chung — connection pool hoặc thread pool chung bị luồng đăng ký giữ hết. Người giải không nhận ra điều này thì chưa đạt SA2 ở trụ 2. |
| Hướng A — resilience thuần kỹ thuật | Timeout 1 s, circuit breaker mở sau N lỗi liên tiếp, bulkhead tách pool riêng cho lời gọi ra ngoài, retry có jitter và giới hạn. Khi circuit mở thì trả lỗi rõ ràng cho người dùng. Đánh đổi: vẫn không đăng ký được, chỉ là hỏng có kiểm soát. |
| Hướng B — đổi mô hình nghiệp vụ | Nhận đăng ký trước ở trạng thái chờ xác thực, xác thực bất đồng bộ khi API sống lại, thông báo kết quả sau. Giữ được doanh thu trong lúc dependency chết. Đánh đổi: cần quy trình xử lý đơn không xác thực được, cần đàm phán với nghiệp vụ. |
| Ghi chú | Hướng B thường tốt hơn nhưng cần SA dám đặt lại câu hỏi nghiệp vụ thay vì chỉ giải bài toán kỹ thuật được giao. Đây là dấu hiệu SA2–SA3. |
Câu hỏi phản biện dành riêng cho đề này
- Vì sao hệ thống chăm sóc khách hàng chậm theo dù không gọi API đó?
- Timeout của anh là bao nhiêu? Con số đó dựa trên gì?
- Nếu retry, anh retry mấy lần? 20.000 request cùng retry một lúc thì điều gì xảy ra với API đang hấp hối?
- Xác thực có bắt buộc phải đồng bộ không? Ai là người có quyền trả lời câu hỏi đó?
P08 · Tháng 2 · Trụ 5, 6Curveball — ràng buộc thay đổi giữa buổi
Bối cảnh nghiệp vụ
Đề được phát như một bài thiết kế bình thường (panel chọn một đề từ P05–P07). Điểm khác biệt: giữa buổi trình bày, panel công bố một ràng buộc mới và người trình bày phải phản ứng ngay tại chỗ trong 10 phút, vẽ lại phần bị ảnh hưởng.
Ràng buộc định lượng (phát cho người giải)
- Ràng buộc mới do panel chọn, ví dụ: ngân sách hạ tầng giảm 50% · không được dùng managed service · thời gian giao hàng rút từ 4 tháng xuống 6 tuần · quy mô tăng gấp 10 so với đề ban đầu
- Người trình bày có 10 phút suy nghĩ, được dùng giấy, không được hỏi ý kiến người khác
Thông tin cố tình bỏ trống test chủ động hỏi
Toàn bộ ràng buộc mới là thông tin bị giấu có chủ đích. Bài này kiểm tra phản ứng, không kiểm tra chuẩn bị.
Trọng tâm chấm
- Phản ứng đầu tiên là gì — hỏi lại để làm rõ, hay vội sửa thiết kế
- Có xác định được phần nào của thiết kế còn giữ được và phần nào phải bỏ không
- Có nêu rõ cái gì bị hy sinh và hệ quả nghiệp vụ không
- Có giữ được bình tĩnh và mạch lập luận dưới áp lực không (trụ 6)
Đáp án tham chiếu cho panel
| Hướng | Nội dung & đánh đổi |
|---|---|
| Điều panel tìm kiếm | Không phải phương án mới hoàn hảo. Mà là: người trình bày có phân biệt được quyết định nào đảo ngược được và quyết định nào không, và có ưu tiên giữ những thứ khó đảo ngược không. |
| Dấu hiệu SA2 | Trả lời theo cấu trúc: "Ràng buộc này ảnh hưởng tới X và Y. X tôi giữ nguyên vì... Y tôi phải bỏ, hệ quả là... Đổi lại tôi cần nghiệp vụ chấp nhận điều Z." |
| Dấu hiệu chưa đạt | Hoặc bảo vệ cứng thiết kế cũ, hoặc vứt bỏ toàn bộ vẽ lại từ đầu. Cả hai đều cho thấy chưa hiểu phần nào của thiết kế mang giá trị cốt lõi. |
Câu hỏi phản biện dành riêng cho đề này
- Phần nào trong thiết kế của anh vẫn đúng với ràng buộc mới?
- Anh phải bỏ cái gì? Ai là người chịu hậu quả của việc bỏ đó?
- Nếu 3 tháng nữa ràng buộc này được gỡ bỏ, anh có quay lại thiết kế cũ được không? Chi phí bao nhiêu?
P09 · Tháng 3 · Trụ 2, 3B2B CRM — dữ liệu lệch nặng
Bối cảnh nghiệp vụ
Hệ thống CRM cho khách hàng doanh nghiệp. Phân tích dữ liệu cho thấy 8% khách hàng lớn tạo ra 76% tổng số giao dịch, và khách hàng lớn nhất một mình chiếm 12%. Hệ thống hiện chạy chậm bất thường với đúng nhóm khách hàng lớn — cũng chính là nhóm quan trọng nhất về doanh thu.
Ràng buộc định lượng (phát cho người giải)
- 12 triệu giao dịch/tháng, tăng 40%/năm
- Truy vấn lịch sử giao dịch của một khách hàng phải trả trong 2 giây
- Báo cáo tổng hợp toàn hệ thống chạy hàng đêm, hiện mất 6 giờ và đang tăng
- Khách hàng lớn nhất có 1,4 triệu giao dịch
Thông tin cố tình bỏ trống test chủ động hỏi
Không cho biết truy vấn phổ biến nhất là gì, không cho biết dữ liệu cũ bao lâu thì ít được truy cập, không cho biết có yêu cầu truy vấn xuyên khách hàng không.
Trọng tâm chấm
- Có nhận ra đây là bài toán hot partition không, hay chỉ đề xuất "thêm index"
- Có hỏi về access pattern trước khi chọn partition key không
- Có xử lý riêng nhóm khách hàng lớn không
- Có nhận ra báo cáo đêm 6 giờ là bài toán khác với truy vấn 2 giây không
Đáp án tham chiếu cho panel
| Hướng | Nội dung & đánh đổi |
|---|---|
| Chẩn đoán | Partition theo customer_id là lựa chọn tự nhiên nhưng tạo hot partition nghiêm trọng: một shard chứa 12% dữ liệu. Đây là ví dụ kinh điển và là lý do đề này nằm ở tháng 3. |
| Hướng A — composite partition key | Partition theo (customer_id, khoảng thời gian). Khách hàng lớn được trải đều trên nhiều partition theo tháng/quý. Truy vấn lịch sử gần vẫn nhanh. Đánh đổi: truy vấn toàn bộ lịch sử một khách hàng phải quét nhiều partition. |
| Hướng B — tách tầng theo quy mô khách hàng | Nhóm khách hàng lớn có kho riêng, tài nguyên riêng, thậm chí mô hình dữ liệu riêng. Cách ly hoàn toàn ảnh hưởng. Đánh đổi: hai đường code, phải xử lý việc khách hàng chuyển nhóm. |
| Bài toán báo cáo | Báo cáo đêm 6 giờ nên tách hẳn khỏi hệ thống giao dịch — đây là bài toán phân tích, không phải bài toán vận hành. Người giải gộp hai bài toán vào một thiết kế là dấu hiệu chưa phân biệt được OLTP và OLAP. |
Câu hỏi phản biện dành riêng cho đề này
- Mười khách hàng lớn nhất chiếm bao nhiêu phần trăm dữ liệu? Anh đã hỏi con số đó chưa?
- Partition key anh chọn — khách hàng lớn nhất rơi vào bao nhiêu partition?
- Báo cáo đêm và truy vấn 2 giây có nên chạy trên cùng một kho dữ liệu không?
- Năm sau tăng 40%, thiết kế của anh còn đứng được không? Chỗ nào gãy trước?
P10 · Tháng 3 · Trụ 4, 5Build vs Buy — nền tảng dữ liệu khách hàng
Bối cảnh nghiệp vụ
Ban lãnh đạo đang cân nhắc: tự xây nền tảng dữ liệu khách hàng (CDP) hay mua giải pháp thương mại. Bạn được yêu cầu đưa ra khuyến nghị kèm phân tích chi phí ba năm và trình bày trước ban lãnh đạo trong 10 phút.
Ràng buộc định lượng (phát cho người giải)
- Ngân sách đầu tư năm đầu: có giới hạn, do lãnh đạo quyết
- Giải pháp thương mại: chi phí thuê bao theo số hồ sơ khách hàng, tăng theo quy mô
- Tự xây: cần khoảng 5–6 người trong 12 tháng, sau đó 2–3 người vận hành
- Dữ liệu khách hàng viễn thông có ràng buộc lưu trữ trong nước
Thông tin cố tình bỏ trống test chủ động hỏi
Không cho biết chi phí thuê bao cụ thể, không cho biết mức lương trung bình, không cho biết yêu cầu tính năng nào là bắt buộc. Người giải phải tự đặt giả định và nói rõ đó là giả định.
Trọng tâm chấm
- Có phân biệt facts / assumptions rõ ràng không — đây là bài chấm nặng điểm này
- Có tính đủ chi phí vận hành và cơ hội mất đi, không chỉ chi phí phát triển không
- Có nêu chi phí thoát ra (lock-in) của phương án mua không
- Có trình bày bằng ngôn ngữ chi phí và rủi ro thay vì thuật ngữ kỹ thuật không (trụ 6)
Đáp án tham chiếu cho panel
| Hướng | Nội dung & đánh đổi |
|---|---|
| Khung phân tích tối thiểu | Ba năm, bốn khoản: chi phí xây dựng ban đầu · chi phí vận hành hàng năm · chi phí cơ hội (5–6 người này không làm việc khác) · chi phí thoát ra. Thiếu khoản thứ ba và thứ tư là dấu hiệu SA1. |
| Hướng A — mua | Nhanh có giá trị, rủi ro triển khai thấp, chi phí dự đoán được. Đánh đổi: lock-in, chi phí tăng theo quy mô dữ liệu, có thể vướng ràng buộc lưu trữ trong nước, và không xây được năng lực nội bộ. |
| Hướng B — xây | Kiểm soát hoàn toàn, phù hợp ràng buộc dữ liệu, xây được năng lực. Đánh đổi: 12 tháng chưa có giá trị, rủi ro nhân sự nghỉ việc, và chi phí thật thường gấp 1,5–2 lần ước tính ban đầu. |
| Hướng C — thường bị bỏ qua | Mua phần lõi, tự xây phần đặc thù. Hoặc: xây tối giản trước để học bài toán, quyết định mua sau 6 tháng khi đã hiểu rõ nhu cầu. Người giải nêu được hướng thứ ba là dấu hiệu SA2–SA3. |
Câu hỏi phản biện dành riêng cho đề này
- Con số nào trong phân tích của anh là dữ kiện, con số nào là giả định của anh?
- Nếu sau 2 năm muốn đổi nhà cung cấp, chi phí chuyển đổi là bao nhiêu?
- 5 người xây CDP trong 12 tháng — nếu không làm việc này thì họ tạo ra giá trị gì khác?
- Anh trình bày 10 phút trước ban lãnh đạo: câu đầu tiên anh nói là gì?
P11 · Tháng 3 · Trụ 4, 3Tích hợp LLM vào một luồng nghiệp vụ có ràng buộc dữ liệu
Bối cảnh nghiệp vụ
Bộ phận chăm sóc khách hàng muốn dùng LLM để tự động tóm tắt lịch sử tương tác và gợi ý câu trả lời cho nhân viên tổng đài. Dữ liệu đầu vào chứa thông tin cá nhân khách hàng. Kỳ vọng: giảm thời gian xử lý mỗi cuộc gọi.
Ràng buộc định lượng (phát cho người giải)
- Khoảng 15.000 cuộc gọi/ngày, cao điểm 3.000/giờ
- Thông tin cá nhân khách hàng không được gửi ra ngoài lãnh thổ
- Nhân viên tổng đài cần gợi ý trong dưới 3 giây
- Ngân sách vận hành có giới hạn, chi phí theo token
Thông tin cố tình bỏ trống test chủ động hỏi
Không cho biết tỉ lệ gợi ý sai chấp nhận được, không cho biết ai chịu trách nhiệm khi gợi ý sai gây thiệt hại, không cho biết có yêu cầu ghi vết (audit trail) không.
Trọng tâm chấm
- Có xử lý ràng buộc dữ liệu trước khi bàn mô hình không
- Có thiết kế cơ chế kiểm soát chất lượng đầu ra không, hay coi LLM là hộp đen đáng tin
- Có tính chi phí theo token ở quy mô 15.000 cuộc/ngày không
- Có phân biệt được chỗ nào cần LLM và chỗ nào dùng cách rẻ hơn không
Đáp án tham chiếu cho panel
| Hướng | Nội dung & đánh đổi |
|---|---|
| Ràng buộc quyết định kiến trúc | Dữ liệu cá nhân không ra khỏi lãnh thổ → hoặc mô hình chạy trong nước, hoặc phải khử định danh trước khi gửi. Đây là quyết định đầu tiên, mọi thứ khác phụ thuộc vào nó. Người giải bàn kiến trúc RAG trước khi giải quyết ràng buộc này là đi sai thứ tự. |
| Hướng A — RAG với mô hình trong nước | Lịch sử tương tác được index, truy xuất ngữ cảnh liên quan, mô hình sinh tóm tắt. Đáp ứng ràng buộc dữ liệu. Đánh đổi: chất lượng mô hình trong nước thấp hơn, cần vận hành hạ tầng. |
| Hướng B — khử định danh + mô hình bên ngoài | Thay thông tin cá nhân bằng mã trước khi gửi, ghép lại sau. Chất lượng tốt hơn. Đánh đổi: rủi ro rò rỉ nếu khử định danh không kín, độ trễ tăng, phụ thuộc bên ngoài. |
| Điểm ít người nghĩ tới | Không phải cuộc gọi nào cũng cần LLM. Tóm tắt theo mẫu cho các trường hợp phổ biến rẻ hơn nhiều lần và nhanh hơn. Dùng LLM cho phần đuôi phức tạp. Nhận ra điều này là dấu hiệu trụ 4 ở mức SA2–SA3. |
Câu hỏi phản biện dành riêng cho đề này
- Ràng buộc dữ liệu cá nhân ảnh hưởng thế nào tới lựa chọn mô hình? Anh giải quyết nó ở tầng nào?
- 15.000 cuộc/ngày × chi phí token — một tháng hết bao nhiêu? Con số đó có chấp nhận được không?
- Khi LLM gợi ý sai và nhân viên làm theo, ai chịu trách nhiệm? Thiết kế của anh có ghi vết không?
- Bao nhiêu phần trăm cuộc gọi thật sự cần LLM?
P12 · Tháng 3 · Trụ Toàn bộCapstone — kiến trúc lại một hệ thống thật của SU02
Bối cảnh nghiệp vụ
Bài cuối khoá. Panel chọn một hệ thống thật trong portfolio của phòng, kèm PM chủ dự án tham gia buổi với vai trò stakeholder phản biện. Nhóm 2–3 người có 2 tuần để đưa ra kiến trúc mục tiêu và lộ trình chuyển đổi.
Ràng buộc định lượng (phát cho người giải)
- Trình bày 25 phút trước panel + PM chủ dự án
- Bắt buộc có: kiến trúc hiện trạng, kiến trúc mục tiêu, lộ trình chuyển đổi theo giai đoạn, phân tích rủi ro, và ước tính chi phí/nguồn lực
- Bắt buộc có ít nhất 3 ADR cho các quyết định lớn
- Được dùng AI ở giai đoạn viết tài liệu, không được dùng ở giai đoạn thiết kế ban đầu
Thông tin cố tình bỏ trống test chủ động hỏi
Nhóm phải tự làm việc với PM chủ dự án để lấy thông tin — đây là một phần của bài kiểm tra (trụ 6).
Trọng tâm chấm
- Chất lượng câu hỏi đặt cho PM trong 2 tuần chuẩn bị
- Lộ trình chuyển đổi có khả thi với nguồn lực thật của dự án không
- ADR có phần phương án bị loại và lý do không
- Có bảo vệ được trước phản biện của PM — người hiểu nghiệp vụ hơn panel — không
Đáp án tham chiếu cho panel
| Hướng | Nội dung & đánh đổi |
|---|---|
| Vai trò của PM trong buổi này | PM phản biện từ góc nghiệp vụ và nguồn lực: "cái này khách hàng có cần không", "team tôi làm được trong bao lâu". Đây là loại phản biện panel kỹ thuật không tạo ra được, và là phần giá trị nhất của Capstone. |
| Kết quả có thể dùng thật | Nếu đề xuất tốt, đưa vào kế hoạch quý sau của dự án. Điều này biến Dojo từ bài tập thành đầu vào thật cho portfolio — và là lý do mạnh nhất để duy trì chương trình sang chu kỳ tiếp theo. |
Câu hỏi phản biện dành riêng cho đề này
- Nếu chỉ được làm một phần trong lộ trình của anh trong quý tới, phần nào?
- Con số ước tính nguồn lực của anh dựa trên gì?
- PM nói không có người — kiến trúc của anh thay đổi thế nào?
- Điều gì trong đề xuất này anh chắc chắn nhất, và điều gì anh ít chắc nhất?