Mở đầu — vì sao bài này quan trọng
Trong đời sống của một đội kỹ thuật, có một loại câu hỏi luôn xuất hiện và luôn gây tranh cãi: "Chúng ta chọn kiến trúc nào? Ai là người ra quyết định cuối cùng?" Đây có thể là chuyện chọn message queue nào (Kafka hay RabbitMQ), có nên tách một service khổng lồ thành nhiều microservice hay không, hay đơn giản là dùng REST hay gRPC cho một API nội bộ.
Điều làm những quyết định này khác biệt so với quyết định code thông thường là chúng có chi phí đảo ngược cao. Bạn có thể sửa một hàm sai trong 10 phút, nhưng nếu chọn sai database cho hệ thống thanh toán, việc di dời (migration) có thể tốn hàng tháng và làm gián đoạn cả một mùa kinh doanh. Chính vì vậy, cách một tổ chức ra quyết định kiến trúc phản ánh trực tiếp độ trưởng thành kỹ thuật của tổ chức đó.
Nhiều Tech Lead mới lên thường mắc một trong hai cực: hoặc ôm hết mọi quyết định vào mình (trở thành nút thắt cổ chai, làm chậm cả đội và khiến kỹ sư mất động lực), hoặc buông lỏng hoàn toàn (mỗi team tự chọn công nghệ, dẫn đến một mớ hỗn độn không ai bảo trì nổi). Bài học này giúp bạn tìm ra điểm cân bằng: ai nên quyết định cái gì, dựa trên tiêu chí nào, và quyết định đó được ghi lại, phản biện, thực thi ra sao. Đây là kỹ năng cốt lõi phân biệt một senior engineer giỏi với một người thực sự dẫn dắt kỹ thuật.
Khái niệm cốt lõi
Blast radius — thước đo trung tâm
Nguyên tắc quan trọng nhất để trả lời câu hỏi "ai quyết?" chính là blast radius (bán kính ảnh hưởng): nếu quyết định này sai, nó làm hỏng bao nhiêu thứ, và khó sửa đến mức nào?
Hãy hình dung ba vòng tròn đồng tâm:
- Vòng trong cùng — trong một service/module. Quyết định chỉ ảnh hưởng đến một service mà một team sở hữu. Ví dụ: dùng thư viện validation nào bên trong service, cách tổ chức folder, có dùng Redis cache cục bộ hay không. Người quyết: owner của service cùng Tech Lead của team đó. Không cần họp hành lớn.
- Vòng giữa — ảnh hưởng nhiều service/nhiều team. Ví dụ: đổi format của event trên message bus mà 5 team khác cùng đọc; chọn chuẩn xác thực (authentication) dùng chung; thay đổi contract của một API nội bộ quan trọng. Người quyết: cần sự đồng thuận giữa các Tech Lead liên quan, thường qua một cơ chế chính thức như RFC hoặc một hội đồng kiến trúc nhẹ.
- Vòng ngoài cùng — ảnh hưởng toàn tổ chức, khó đảo ngược. Ví dụ: chọn cloud provider chính, chọn ngôn ngữ lập trình chuẩn cho backend, quyết định đi theo monolith hay microservices ở tầm công ty. Người quyết: Principal Engineer / Architect / CTO, sau khi thu thập input rộng rãi. Đây là những "one-way door" — cửa một chiều.
One-way door vs. two-way door
Khái niệm này được Amazon phổ biến và cực kỳ hữu ích. Two-way door (cửa hai chiều) là quyết định dễ đảo ngược: nếu sai, bạn bước lui lại được với chi phí thấp. Với loại này, hãy quyết nhanh, giao cho người gần vấn đề nhất, đừng họp ba tuần. One-way door (cửa một chiều) là quyết định gần như không thể quay đầu, hoặc quay đầu với chi phí khổng lồ. Với loại này, hãy chậm lại, thu thập dữ liệu, viết ra giấy, mời phản biện.
Sai lầm phổ biến nhất là đối xử với two-way door như one-way door (phân tích quá mức, làm chậm cả đội) và ngược lại, đối xử với one-way door như two-way door (quyết vội, hối hận cả năm).
ADR — Architecture Decision Record
Quyết định không chỉ cần được đưa ra, mà cần được ghi lại kèm lý do. ADR là một tài liệu ngắn (thường 1 trang) ghi lại: bối cảnh (context), quyết định (decision), các phương án đã cân nhắc, và hệ quả (consequences). Sáu tháng sau, khi một kỹ sư mới nhìn vào và hỏi "tại sao hồi đó lại chọn PostgreSQL thay vì MongoDB?", ADR trả lời thay bạn. Không có ADR, mọi quyết định trở thành "tri thức bộ lạc" nằm trong đầu vài người, và biến mất khi họ nghỉ việc.
Vai trò của Tech Lead: người điều phối, không phải nhà độc tài
Điểm mấu chốt: vai trò của Tech Lead trong quyết định kiến trúc thường không phải là "người luôn đúng", mà là người đảm bảo quy trình quyết định lành mạnh diễn ra. Bạn đảm bảo đúng người được tham gia, đúng phương án được cân nhắc, tranh luận dựa trên dữ liệu chứ không phải cái tôi, và cuối cùng có một quyết định rõ ràng thay vì tê liệt. Một Tech Lead giỏi thắng bằng việc giúp cả đội đưa ra quyết định tốt, chứ không phải bằng việc luôn áp đặt ý mình.
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "mỗi team một database"
Một công ty thương mại điện tử lớn tại Việt Nam (tạm hình dung theo mô hình Tiki giai đoạn tăng trưởng nóng) từng trao toàn quyền chọn công nghệ cho từng team để tăng tốc độ. Kết quả sau 18 tháng: hệ thống có 4 loại database khác nhau (PostgreSQL, MySQL, MongoDB, và một team dùng cả Cassandra), 3 message queue, và không đội on-call nào đủ chuyên môn để xử lý sự cố xuyên hệ thống lúc 2 giờ sáng.
Vấn đề gốc: họ đã đối xử với một quyết định vòng ngoài cùng (chọn database chuẩn) như thể nó là vòng trong cùng. Chọn database là two-way door với một service nhỏ, nhưng khi nhân lên toàn tổ chức, nó trở thành one-way door về mặt vận hành và tuyển dụng.
Cách khắc phục họ áp dụng: lập một Tech Radar ở tầm công ty, phân loại công nghệ thành "Adopt / Trial / Hold". PostgreSQL và Kafka được đưa vào "Adopt" làm mặc định; muốn dùng thứ khác, team phải viết RFC giải thích vì sao trường hợp của mình cần ngoại lệ. Bài học: quyền tự do chọn công nghệ nên tỉ lệ nghịch với blast radius. Tự do trong service — hoan nghênh; tự do làm phân mảnh cả tổ chức — cần có rào.
Tình huống 2 — Startup fintech và quyết định "cửa một chiều" về schema thanh toán
Một startup fintech Đông Nam Á (khoảng 25 kỹ sư) cần thiết kế schema cho hệ thống sổ cái (ledger) thanh toán. Một senior engineer đề xuất mô hình "single-entry" đơn giản để ship nhanh trong 2 tuần. Tech Lead nhận ra đây là one-way door: một khi tiền thật đã chạy qua và hàng triệu bản ghi được tạo, việc đổi mô hình sổ cái sau này gần như bất khả thi mà không dừng dịch vụ.
Thay vì quyết trong cuộc họp đứng 15 phút, Tech Lead yêu cầu viết một RFC/ADR. Trong quá trình viết, đội phát hiện single-entry không thể biểu diễn được các nghiệp vụ hoàn tiền và đối soát. Họ chuyển sang mô hình double-entry (ghi kép, chuẩn kế toán) — tốn thêm 3 tuần lúc đầu, nhưng cứu họ khỏi một cuộc migration địa ngục về sau.
Điểm tinh tế: chi phí viết ADR (khoảng 2 ngày) là rất nhỏ so với blast radius. Bài học: hãy đầu tư nỗ lực quyết định tương xứng với chi phí đảo ngược. Với cửa một chiều liên quan đến tiền, dữ liệu người dùng, hoặc contract công khai — luôn chậm lại và viết ra giấy.
Tình huống 3 — Grab và cuộc tranh luận REST vs gRPC không hồi kết
Tại một tổ chức kỹ thuật lớn kiểu Grab, hai team liên tục tranh cãi nên dùng REST hay gRPC cho giao tiếp giữa các service. Cuộc tranh luận kéo dài nhiều tuần trên Slack, mỗi bên viện dẫn benchmark, và không ai có thẩm quyền chốt. Đây là biểu hiện của decision paralysis (tê liệt quyết định) do thiếu chủ sở hữu rõ ràng.
Giải pháp: nhóm Principal Engineer thành lập một Architecture Review nhẹ họp hai tuần một lần. Với câu hỏi REST vs gRPC, họ ra một hướng dẫn: gRPC là mặc định cho giao tiếp service-to-service nội bộ (hiệu năng, contract chặt qua Protobuf), REST cho các API hướng ra ngoài và cho các đối tác. Quyết định được ghi thành ADR, và cuộc tranh luận kết thúc.
Bài học kép: thứ nhất, thiếu chủ sở hữu quyết định còn tệ hơn một quyết định chưa hoàn hảo — sự tê liệt tiêu tốn năng lượng và niềm tin của đội. Thứ hai, nhiều tranh cãi kiến trúc thực chất nên được giải quyết bằng một default (mặc định) ở tầm tổ chức thay vì tranh luận lại từ đầu cho mỗi dự án.
Hướng dẫn từng bước
Khi đứng trước một quyết định kiến trúc, đây là quy trình bạn có thể áp dụng ngay:
Bước 1 — Xác định blast radius. Hỏi thẳng: "Nếu chọn sai, bao nhiêu team/service bị ảnh hưởng, và sửa lại tốn bao lâu?" Trả lời câu này quyết định phần lớn quy trình còn lại. Ảnh hưởng một service → xử lý trong team. Nhiều team → cần đồng thuận. Toàn tổ chức → cần cấp Principal/Architect.
Bước 2 — Phân loại cửa một chiều hay hai chiều. Nếu là two-way door, ưu tiên tốc độ: giao cho người gần vấn đề nhất, quyết trong ngày, ghi lại ngắn gọn. Nếu là one-way door, chuyển sang chế độ cẩn trọng: bắt buộc viết ADR/RFC.
Bước 3 — Chỉ định rõ người ra quyết định (decision owner). Mỗi quyết định phải có đúng một người chịu trách nhiệm chốt. Có thể tham khảo mô hình DACI: Driver (người đẩy), Approver (người phê duyệt), Contributors (người đóng góp), Informed (người được thông báo). Mơ hồ ở khâu này là nguyên nhân số một gây tê liệt.
Bước 4 — Liệt kê tối thiểu 2–3 phương án kèm trade-off. Một quyết định chỉ có một phương án không phải quyết định, mà là quán tính. Với mỗi phương án, ghi rõ được gì, mất gì, chi phí vận hành, và rủi ro.
Bước 5 — Viết ADR. Cấu trúc tối thiểu: Context (bối cảnh, ràng buộc) → Options considered (các phương án) → Decision (chọn gì) → Consequences (hệ quả, cả tốt lẫn xấu). Giữ nó ngắn, một trang là đủ.
Bước 6 — Mở phản biện có thời hạn. Chia sẻ ADR cho những người liên quan với một deadline rõ ràng (ví dụ: "phản hồi trước thứ Sáu"). Không có deadline, phản biện kéo dài vô tận. Tranh luận trên tài liệu, không tranh luận bằng cái tôi.
Bước 7 — Chốt, ghi lại, và truyền đạt. Sau deadline, decision owner chốt. Cập nhật ADR sang trạng thái "Accepted", thông báo cho nhóm Informed, và bắt đầu thực thi. Quan trọng: một khi đã chốt, cả đội disagree and commit — có thể không đồng ý nhưng vẫn cam kết thực hiện.
Lỗi thường gặp & mẹo
Lỗi 1 — HiPPO quyết định. HiPPO là "Highest Paid Person's Opinion" (ý kiến của người lương cao nhất). Khi quyết định kiến trúc chỉ dựa vào việc ai to tiếng nhất hoặc ai chức cao nhất trong phòng, chất lượng kỹ thuật sụp đổ và kỹ sư giỏi mất động lực. Mẹo: buộc mọi lập luận phải neo vào dữ liệu, ràng buộc thực tế, và trade-off cụ thể — không phải thâm niên.
Lỗi 2 — Bikeshedding. Đội dành 2 tiếng cãi nhau về tên biến hoặc màu nút, nhưng lướt qua quyết định chọn database trong 5 phút. Con người có xu hướng tranh luận nhiều nhất về thứ dễ hiểu nhất, bất kể tầm quan trọng. Mẹo: luôn phân bổ thời gian và sự nghiêm túc theo blast radius, không theo mức độ dễ tranh luận.
Lỗi 3 — Tech Lead trở thành nút thắt cổ chai. Nếu mọi quyết định dù nhỏ đều phải qua bạn, bạn đang giết chết tốc độ của đội và cả sự phát triển của họ. Mẹo: chủ động ủy quyền các quyết định two-way door trong service cho chính owner, chỉ giữ lại cho mình vai trò trong các quyết định có blast radius lớn.
Lỗi 4 — Không có ADR, tri thức thành "bộ lạc". Sáu tháng sau không ai nhớ vì sao chọn công nghệ đó, và đội lặp lại tranh luận cũ. Mẹo: biến việc viết ADR thành thói quen mặc định cho mọi quyết định vòng giữa trở lên. Chi phí một trang giấy rẻ hơn nhiều lần một cuộc tranh luận lặp lại.
Lỗi 5 — Quyết định vĩnh viễn, không bao giờ xem lại. Bối cảnh thay đổi; một quyết định đúng năm 2022 có thể sai năm 2026. Mẹo: đánh dấu ADR có thể chuyển sang trạng thái "Superseded" (bị thay thế) khi cần, và định kỳ rà soát các quyết định lớn.
Mẹo bonus — "Strong opinions, loosely held". Hãy có quan điểm mạnh mẽ dựa trên hiểu biết, nhưng sẵn sàng thay đổi khi có dữ liệu tốt hơn. Đây là văn hóa giúp tranh luận kiến trúc lành mạnh mà không biến thành chiến tranh cái tôi.
Bài tập thực hành
Bài tập 1 — Phân loại blast radius. Lấy 5 quyết định kỹ thuật gần nhất trong team bạn (hoặc dự án cá nhân). Với mỗi cái, xác định: nó thuộc vòng nào (trong service / nhiều team / toàn tổ chức), là one-way hay two-way door, và ai lẽ ra nên là người quyết. So sánh với thực tế đã diễn ra — có sai lệch nào không?
Bài tập 2 — Viết một ADR hoàn chỉnh. Chọn một quyết định thật (ví dụ: chọn giữa REST và gRPC, hoặc chọn database cho một tính năng mới). Viết một ADR một trang gồm đủ 4 phần: Context, Options considered (tối thiểu 3 phương án với trade-off), Decision, Consequences. Mục tiêu: luyện tư duy trình bày trade-off rõ ràng.
Bài tập 3 — Thiết kế mô hình quyết định cho team. Giả sử bạn vừa được giao làm Tech Lead một team 8 người. Hãy viết ra một trang "hiến pháp quyết định kiến trúc" cho team: loại quyết định nào owner tự quyết, loại nào cần Tech Lead, loại nào cần đưa lên trên, và khi nào bắt buộc viết ADR. Chia sẻ với một đồng nghiệp và xin phản biện.
Tóm tắt
Quyết định kiến trúc không phải chuyện "ai giỏi nhất thì quyết", mà là chuyện thiết kế một quy trình quyết định lành mạnh. Ba ý cần nhớ:
- Blast radius là la bàn. Quyết định ảnh hưởng một service thì owner cùng Tech Lead chốt; ảnh hưởng nhiều team cần đồng thuận qua RFC; ảnh hưởng toàn tổ chức cần cấp Principal/Architect. Quyền tự do nên tỉ lệ nghịch với bán kính ảnh hưởng.
- Phân biệt cửa một chiều và hai chiều. Two-way door thì quyết nhanh, giao cho người gần vấn đề. One-way door thì chậm lại, viết ADR, mời phản biện. Đầu tư nỗ lực tương xứng với chi phí đảo ngược.
- Vai trò Tech Lead là người điều phối, không phải nhà độc tài. Bạn đảm bảo đúng người tham gia, đúng phương án được cân nhắc, tranh luận dựa trên dữ liệu, và cuối cùng có một quyết định rõ ràng được ghi lại. Tránh HiPPO, tránh bikeshedding, tránh trở thành nút thắt cổ chai — và luôn "disagree and commit" một khi đã chốt.