Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là một kiến trúc sư phần mềm ở một startup fintech tại TP.HCM. Một kỹ sư senior của team Payments gửi cho bạn một thiết kế mới cho hệ thống đối soát giao dịch. Nhìn qua thì gọn gàng, sơ đồ đẹp, code sạch. Ba tháng sau khi lên production, hệ thống bắt đầu mất dữ liệu đối soát mỗi khi có sự cố mạng, vì thiết kế đã bỏ qua vấn đề idempotency và cơ chế retry an toàn. Chi phí để sửa lúc này không còn là vài giờ review, mà là hàng tuần refactor, cộng thêm những đêm mất ngủ vì tiền của khách bị lệch sổ.
Đây chính là lý do Architecture Review tồn tại. Nó là một quy trình có chủ đích để phát hiện thiết kế tồi từ sớm, khi việc sửa còn rẻ. Một quyết định kiến trúc sai được bắt trên tài liệu tốn vài giờ tranh luận; cũng quyết định đó lọt xuống production có thể tốn hàng trăm giờ công và uy tín với khách hàng.
Nhưng Architecture Review không chỉ là "bắt lỗi". Trong suốt khóa học này, chúng ta đã học cách viết ADR (Bài 4-5), phân tích trade-off (Bài 6), chọn database, chọn message broker, thiết kế cho scalability và reliability. Architecture Review chính là cơ chế tổ chức để tất cả những kỹ năng đó được kiểm chứng bởi tập thể trước khi biến thành cam kết kỹ thuật lâu dài. Nó là nơi kiến thức được chia sẻ, nơi các tiêu chuẩn của tổ chức được thực thi, và nơi những phụ thuộc chéo giữa các team được phát hiện trước khi chúng trở thành nút thắt cổ chai.
Ở cấp độ Senior và đặc biệt là Principal (mà Bài 60 sẽ nói kỹ), khả năng chạy một buổi review hiệu quả — không phải để "gác cổng" mà để "nâng cấp" — là một trong những kỹ năng phân biệt người kỹ sư giỏi với người lãnh đạo kỹ thuật thực thụ.
Khái niệm cốt lõi
Architecture Review là gì và không phải là gì
Architecture Review là một quy trình đánh giá có cấu trúc một đề xuất thiết kế kiến trúc trước khi nó được triển khai. Nó tập trung vào các quyết định khó đảo ngược — cách chia service, chọn công nghệ nền tảng, mô hình dữ liệu, ranh giới giữa các hệ thống.
Điều quan trọng là hiểu nó không phải là gì:
- Không phải là code review. Code review xét từng dòng code, style, bug cụ thể. Architecture Review xét quyết định cấu trúc — thứ mà một khi đã chọn thì rất tốn kém để thay đổi.
- Không phải là cổng gác quan liêu (bureaucratic gate) để làm chậm mọi thứ. Nếu review biến thành nơi mọi thay đổi nhỏ đều phải xin phép, nó sẽ bị team né tránh và mất tác dụng.
- Không phải là nơi để người review "khoe kiến thức" hay áp đặt sở thích cá nhân.
Bốn mục tiêu chính của Architecture Review
Dựa trên chính ý định gốc của bài này, có bốn giá trị cốt lõi mà một buổi review tốt mang lại:
1. Bắt thiết kế tồi từ sớm (catch bad design early). Chi phí sửa một quyết định kiến trúc tăng theo cấp số nhân qua các giai đoạn. Sửa trên whiteboard: gần như miễn phí. Sửa trong tài liệu ADR: vài giờ. Sửa sau khi code xong: vài ngày. Sửa sau khi lên production và có dữ liệu thật: có thể là dự án migration kéo dài nhiều tháng (nhớ lại Strangler Fig ở Bài 56).
2. Chia sẻ tri thức (knowledge share). Khi một team trình bày thiết kế, những người khác học được về domain đó, về các trade-off, về công nghệ mới. Người review cũng học được cách suy nghĩ của người thiết kế. Đây là cơ chế lan truyền kiến thức mạnh nhất trong một tổ chức kỹ thuật.
3. Đồng bộ với tiêu chuẩn tổ chức (align với org standards). Công ty có thể đã chuẩn hóa dùng PostgreSQL, Kafka, và một bộ observability chung. Review đảm bảo thiết kế mới không tự ý dùng công nghệ thứ N chỉ vì một kỹ sư thích, tạo ra gánh nặng vận hành.
4. Phát hiện phụ thuộc chéo (cross-team dependencies). Team A thiết kế một service gọi đồng bộ sang service của Team B mà không báo trước. Nếu không có review, phụ thuộc này chỉ lộ ra khi đã quá muộn. Review là nơi các ranh giới tổ chức được đối chiếu với ranh giới kỹ thuật.
Các mô hình review phổ biến
Không có một mô hình duy nhất đúng. Tùy quy mô tổ chức, bạn sẽ thấy các dạng sau:
- RFC / Design Doc + async review: Người thiết kế viết một tài liệu (thường dựa trên ADR), gửi cho một nhóm, mọi người comment bất đồng bộ trong vài ngày. Phù hợp với team phân tán (như nhiều công ty product ở Việt Nam có team ở HN và HCM).
- Architecture Review Board (ARB): Một hội đồng cố định gồm các kiến trúc sư/tech lead họp định kỳ để duyệt các đề xuất lớn. Phù hợp tổ chức lớn, nhưng dễ trở thành nút thắt nếu không cẩn thận.
- Lightweight sync review: Một buổi họp 45-60 phút, người thiết kế trình bày, nhóm nhỏ 3-5 người phản biện. Linh hoạt, nhanh, phù hợp startup và scale-up.
- RFC công khai (open RFC): Ai trong công ty cũng có thể đọc và góp ý. Tạo văn hóa minh bạch, nhưng cần kỷ luật để không loãng.
Tình huống thực tế
Ví dụ 1: Startup logistics ở Hà Nội — review cứu một quyết định database
Một startup logistics 40 người ở Hà Nội đang xây hệ thống theo dõi đơn hàng thời gian thực. Một kỹ sư đề xuất dùng MongoDB làm database chính cho toàn bộ hệ thống, lập luận rằng "schema linh hoạt, dễ scale". Anh viết một ADR gọn gàng và đưa vào buổi lightweight review thứ Sáu hàng tuần.
Trong buổi review 50 phút, một kiến trúc sư đặt câu hỏi: "Nghiệp vụ đối soát cước vận chuyển giữa shipper và khách có cần transaction đa bảng không?" Câu trả lời là có — mỗi lần chốt cước phải cập nhật đồng thời ví shipper, sổ công nợ khách, và trạng thái đơn. Đây là workload OLTP điển hình cần transaction mạnh (nhớ Bài 26, 28). MongoDB tại thời điểm đó sẽ khiến team phải tự viết logic bù trừ phức tạp.
Kết quả: team quyết định dùng PostgreSQL cho phần giao dịch tài chính, và chỉ dùng document store cho phần lưu trữ log sự kiện di chuyển (nơi schema thật sự linh hoạt). Một quyết định "một database cho tất cả" đã được tách thành hai lựa chọn đúng chỗ.
Bài học: Buổi review không bác bỏ ý tưởng của kỹ sư. Nó đặt một câu hỏi đúng về NFR và workload, và giúp thiết kế trở nên tinh tế hơn. Chi phí: 50 phút. Chi phí nếu không review: nhiều tháng vật lộn với dữ liệu tiền bạc bị lệch.
Ví dụ 2: Grab / một siêu ứng dụng Đông Nam Á — phát hiện phụ thuộc chéo
Ở một tổ chức lớn kiểu siêu ứng dụng (ví dụ mô hình như Grab), team Food đề xuất một service tính khuyến mãi mới. Thiết kế của họ gọi đồng bộ (synchronous) sang service Ví (Wallet) của team Payments mỗi lần render giỏ hàng, để kiểm tra số dư áp mã.
Trong buổi Architecture Review có mặt đại diện team Payments, người này lập tức chỉ ra vấn đề: service Ví đang phục vụ hàng chục nghìn request/giây và có SLA rất chặt. Việc thêm một luồng gọi đồng bộ từ mỗi lần render giỏ hàng Food sẽ tăng tải đột biến và tạo coupling nguy hiểm — nếu Food gặp bug gây gọi lặp, nó có thể kéo sập cả hệ thống thanh toán (cascading failure).
Giải pháp đưa ra sau review: chuyển sang mô hình bất đồng bộ — Food chỉ đọc một bản cache số dư "đủ dùng" và chỉ gọi đồng bộ sang Ví ở bước cuối cùng khi thực sự trừ tiền, kèm circuit breaker (Bài 41) để bảo vệ.
Bài học: Nếu team Payments không có mặt trong buổi review, phụ thuộc chéo này chỉ lộ ra khi load test hoặc tệ hơn là sự cố production. Đây là minh chứng rõ nhất cho mục tiêu "phát hiện cross-team dependencies". Một buổi review đúng người còn quan trọng hơn một buổi review đông người.
Ví dụ 3: Ngân hàng số — khi review board trở thành nút thắt
Một ngân hàng số tại Việt Nam thiết lập một Architecture Review Board rất nghiêm ngặt: mọi thay đổi kiến trúc, dù nhỏ đến đâu, phải qua hội đồng họp hai tuần một lần. Ban đầu nghe rất "chuẩn". Nhưng sau sáu tháng, các team bắt đầu than phiền: một thay đổi nhỏ như thêm một cache Redis cũng phải chờ hai tuần. Hệ quả là các kỹ sư bắt đầu "lách" — họ triển khai trước rồi mới xin duyệt cho có, biến review thành thủ tục hình thức.
Ngân hàng này sửa lại quy trình bằng cách phân ngưỡng (threshold): chỉ những quyết định vượt một ngưỡng tác động nhất định — ảnh hưởng nhiều team, chọn công nghệ nền tảng mới, thay đổi mô hình dữ liệu lõi, hoặc có yếu tố bảo mật/tuân thủ — mới cần lên board. Phần còn lại được duyệt nội bộ trong team bởi một tech lead. Tốc độ tăng trở lại, và board tập trung được vào những quyết định thật sự quan trọng.
Bài học: Review phải có ngưỡng rõ ràng (liên hệ trực tiếp với tư duy threshold ở Bài 5 về ADR). Review quá ít thì lọt lỗi; review quá nhiều thì bóp nghẹt tốc độ và bị né tránh. Nghệ thuật là tìm đúng ngưỡng.
Hướng dẫn từng bước
Đây là một quy trình Architecture Review thực dụng mà bạn có thể áp dụng ngay cho team mình.
Bước 1 — Xác định ngưỡng cần review. Trước tiên, định nghĩa rõ loại quyết định nào cần review. Gợi ý: thay đổi ảnh hưởng từ 2 team trở lên, đưa vào công nghệ nền tảng mới, thay đổi ranh giới service/bounded context, quyết định có tác động bảo mật/chi phí/compliance lớn. Viết ngưỡng này ra và công khai để không ai phải đoán.
Bước 2 — Chuẩn bị tài liệu trước (pre-read). Người đề xuất viết một design doc dựa trên cấu trúc ADR: bối cảnh, vấn đề, các phương án đã cân nhắc, phương án chọn và lý do, các trade-off, tác động đến NFR (performance, reliability, security), và các phụ thuộc. Gửi tài liệu này trước buổi họp ít nhất 2 ngày. Đây là điểm mấu chốt: người review phải đọc trước, không đọc lần đầu trong phòng họp.
Bước 3 — Chọn đúng người review. Không cần đông. Cần đúng: một người hiểu domain, một người hiểu về operability/vận hành, và đại diện của bất kỳ team nào bị ảnh hưởng bởi phụ thuộc chéo. Với quyết định lớn, thêm một kiến trúc sư/principal.
Bước 4 — Chạy buổi review có cấu trúc. Đề nghị người đề xuất trình bày ngắn (10-15 phút) tập trung vào quyết định và trade-off, không sa đà vào chi tiết implementation. Sau đó dành phần lớn thời gian cho phản biện. Dùng một checklist để không bỏ sót (xem bài tập bên dưới).
Bước 5 — Phân loại phản hồi. Không phải comment nào cũng ngang nhau. Hãy phân rõ: Blocking (phải giải quyết trước khi làm), Non-blocking / suggestion (nên cân nhắc), và Question (chỉ để hiểu rõ). Cách phân loại này giúp người đề xuất biết cái gì thật sự cản đường.
Bước 6 — Ghi lại quyết định. Kết quả buổi review phải quay lại chính ADR: cập nhật phương án được chọn, ghi lại các phản biện quan trọng và cách xử lý. Điều này bảo toàn lý do (rationale) cho người sau — sáu tháng nữa khi ai đó hỏi "tại sao lại làm thế này", câu trả lời nằm sẵn trong tài liệu.
Bước 7 — Theo dõi (follow-up). Với các điểm blocking, cần có một vòng xác nhận đã xử lý xong trước khi bắt đầu triển khai. Đừng để review kết thúc bằng "ừ tốt rồi" mà không ai kiểm tra lại các điểm đã nêu.
Lỗi thường gặp & mẹo
Lỗi 1 — Biến review thành phiên "gác cổng" tiêu cực. Người review chỉ chăm chăm tìm lý do bác bỏ, tạo tâm lý sợ hãi. Kết quả: team giấu thiết kế, review mất tác dụng. Mẹo: đặt tinh thần review là "cùng làm cho thiết kế tốt hơn", không phải "duyệt hay đánh trượt". Người review giỏi nêu vấn đề bằng câu hỏi, không bằng phán xét.
Lỗi 2 — Review quá muộn. Đưa thiết kế ra review khi đã code xong 80%. Lúc này mọi phản hồi đều vô ích vì chi phí sửa quá cao, và buổi review chỉ còn là hình thức. Mẹo: review ở giai đoạn quyết định, khi mọi thứ còn trên tài liệu và còn có thể đổi hướng.
Lỗi 3 — Bikeshedding (tranh cãi chuyện nhỏ). Cả buổi họp sa đà vào việc đặt tên biến hay chọn thư viện phụ, trong khi quyết định về ranh giới service — thứ thật sự quan trọng — lại bị bỏ qua. Mẹo: người điều phối phải liên tục kéo cuộc thảo luận về những quyết định khó đảo ngược nhất.
Lỗi 4 — Không đọc trước. Mọi người vào phòng và đọc tài liệu lần đầu, mất nửa buổi chỉ để hiểu bối cảnh. Mẹo: nếu chưa ai đọc pre-read, hãy hoãn buổi họp. Đây là quy tắc mà nhiều tổ chức kỹ thuật lớn áp dụng nghiêm.
Lỗi 5 — Quyết định không được ghi lại. Buổi review kết thúc với nhiều insight hay nhưng không cập nhật vào ADR. Sáu tháng sau không ai nhớ tại sao lại chọn phương án đó. Mẹo: luôn coi việc cập nhật ADR là bước bắt buộc để "đóng" một buổi review.
Mẹo tổng quát: Đo lường sức khỏe của quy trình review bằng câu hỏi đơn giản: "Team có muốn đưa thiết kế ra review không, hay họ né tránh?" Nếu họ né tránh, quy trình của bạn đang có vấn đề — thường là quá chậm, quá tiêu cực, hoặc ngưỡng sai.
Bài tập thực hành
Bài 1 — Xây checklist review cho team bạn. Soạn một checklist Architecture Review gồm 8-12 câu hỏi bao trùm các khía cạnh: NFR (performance, reliability, security), khả năng vận hành (observability, deploy, rollback), phụ thuộc chéo, mô hình dữ liệu, và các trade-off chính. Mỗi câu hỏi phải là dạng "mở" buộc người thiết kế phải suy nghĩ, ví dụ: "Điều gì xảy ra khi service phụ thuộc này ngừng hoạt động?"
Bài 2 — Đóng vai review. Lấy một thiết kế thật (hoặc một ADR bạn từng viết) và tổ chức một buổi review giả 45 phút với 2-3 đồng nghiệp. Yêu cầu mọi người phân loại phản hồi thành Blocking / Suggestion / Question. Sau đó, cập nhật lại ADR dựa trên kết quả. Ghi lại: có bao nhiêu điểm Blocking mà bạn tự mình không nhìn ra?
Bài 3 — Định nghĩa ngưỡng review cho tổ chức của bạn. Viết ra một tài liệu ngắn nêu rõ: loại quyết định nào bắt buộc qua Architecture Review, loại nào chỉ cần duyệt trong team. Đối chiếu với Ví dụ 3 (ngân hàng số) để tránh cả hai thái cực: quá nhiều hoặc quá ít.
Tóm tắt
Architecture Review là cơ chế tổ chức để bắt thiết kế tồi từ sớm — khi việc sửa còn rẻ — thông qua bốn giá trị cốt lõi: phát hiện lỗi sớm, chia sẻ tri thức, đồng bộ với tiêu chuẩn tổ chức, và lộ ra các phụ thuộc chéo giữa các team.
Những điểm cần nhớ:
- Review tập trung vào quyết định khó đảo ngược, không phải chi tiết code.
- Đặt ngưỡng rõ ràng: review quá ít thì lọt lỗi, quá nhiều thì bóp nghẹt tốc độ và bị né tránh.
- Đọc trước tài liệu, trình bày ngắn tập trung vào trade-off, dành thời gian cho phản biện.
- Chọn đúng người — đặc biệt là đại diện các team bị ảnh hưởng — quan trọng hơn chọn đông người.
- Phân loại phản hồi (Blocking / Suggestion / Question) và luôn ghi lại quyết định vào ADR.
- Giữ tinh thần "cùng nâng cấp thiết kế", không phải "gác cổng".