Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng team của bạn chuẩn bị chuyển toàn bộ hệ thống thanh toán từ một monolith sang microservices. Đây là quyết định ảnh hưởng đến hàng chục engineer, kéo dài nhiều tháng, và nếu sai lầm thì chi phí sửa chữa có thể lên tới hàng tỷ đồng. Bạn sẽ làm gì? Nhảy vào code luôn? Họp một buổi 30 phút rồi "chốt"? Hay gõ vài dòng trong Slack rồi hy vọng mọi người đồng ý?
Đây chính là lúc RFC (Request for Comments) phát huy sức mạnh. RFC là một tài liệu viết ra để đề xuất một thay đổi kỹ thuật lớn, mô tả rõ vấn đề, giải pháp đề xuất, các phương án thay thế, và mời cả team đọc, phản biện, đóng góp trước khi bắt tay vào xây dựng. Nó là cách các công ty như Stripe, Cloudflare, Google, Uber ra những quyết định kỹ thuật quan trọng mà không biến thành cãi vã trong phòng họp hay hối hận sau sáu tháng.
Ở bài này, chúng ta tập trung hoàn toàn vào quy trình RFC — một dạng communication đặc thù của tech team. Ở các bài sau bạn sẽ học ADR (ghi lại quyết định kiến trúc sau khi đã chốt) và Code Review Communication (bàn về từng dòng code cụ thể). RFC nằm ở tầng khác: nó là công cụ để cả team suy nghĩ cùng nhau về một thay đổi lớn trước khi một dòng code nào được viết. Nắm vững kỹ năng này, bạn không chỉ viết được tài liệu tốt hơn — bạn học được cách thuyết phục bằng lập luận có cấu trúc, một trong những kỹ năng đắt giá nhất của một senior engineer.
Khái niệm cốt lõi
RFC là gì và không phải là gì
RFC là một tài liệu bằng văn bản (thường 1–5 trang) đề xuất một thay đổi kỹ thuật có phạm vi rộng — ví dụ: đổi database, thêm một hệ thống queue, thay đổi cách các service giao tiếp, hay áp dụng một framework mới cho toàn công ty. Điểm mấu chốt: RFC được viết để mời phản biện, không phải để thông báo quyết định đã rồi.
RFC không phải là:
- Một tài liệu để "xin phép sếp" cho có lệ.
- Một bản thiết kế chi tiết đến từng hàm (đó là design doc kỹ thuật sâu hơn).
- Một quyết định đã chốt sẵn rồi mới đi hỏi ý kiến để hợp thức hóa.
Khi nào cần một RFC?
Không phải thay đổi nào cũng cần RFC — nếu bắt viết RFC cho mọi thứ, team sẽ chết ngộp trong giấy tờ. Bạn nên viết RFC khi thay đổi có ít nhất một trong các đặc điểm sau:
- Khó đảo ngược (irreversible): đổi ngôn ngữ, đổi database, đổi kiến trúc lõi.
- Ảnh hưởng nhiều team: một quyết định làm thay đổi cách các team khác làm việc.
- Tốn nhiều công sức: dự án kéo dài nhiều tuần hoặc nhiều tháng.
- Gây tranh cãi: có nhiều luồng ý kiến trái chiều mà chưa ai đúng rõ ràng.
Cấu trúc một RFC điển hình
Dù mỗi công ty có template riêng, hầu hết RFC tốt đều gồm các phần sau:
- Tiêu đề, tác giả, ngày, trạng thái (Draft / In Review / Accepted / Rejected).
- Summary (Tóm tắt): 2–3 câu trả lời "chúng ta đề xuất làm gì và tại sao".
- Motivation / Problem (Động cơ / Vấn đề): vì sao phải giải quyết bây giờ, đau ở đâu.
- Proposed Solution (Giải pháp đề xuất): chi tiết đủ để người đọc hình dung, kèm sơ đồ nếu cần.
- Alternatives Considered (Các phương án đã cân nhắc): đây là phần quan trọng nhất — cho thấy bạn đã suy nghĩ nghiêm túc và giúp reviewer không phải hỏi lại "sao không dùng cách X?".
- Trade-offs & Risks (Đánh đổi & Rủi ro): mọi giải pháp đều có cái giá của nó, hãy trung thực.
- Open Questions (Câu hỏi mở): những điểm bạn chưa chắc và muốn team cùng giải.
Vòng đời của một RFC
Một RFC đi qua các trạng thái: Draft (tác giả viết) → In Review / Open for Comments (mở cho team góp ý trong một khoảng thời gian cố định, ví dụ 1 tuần) → Accepted hoặc Rejected (có người ra quyết định cuối) → Implemented (đã triển khai) hoặc Superseded (bị thay thế bởi RFC mới). Điểm chết người mà nhiều team hay bỏ sót: phải có deadline rõ ràng cho giai đoạn comment, và phải có một người chịu trách nhiệm ra quyết định cuối (thường là tech lead, staff engineer, hoặc một nhóm nhỏ), nếu không RFC sẽ trôi nổi mãi mãi không bao giờ được "chốt".
Tình huống thực tế
Tình huống 1: Startup fintech Việt Nam và quyết định message queue
Một startup fintech ở TP.HCM khoảng 25 engineer đang gặp vấn đề: hệ thống gửi thông báo giao dịch bị nghẽn vào giờ cao điểm, đôi khi khách hàng nhận SMS chậm 5–10 phút. Một senior backend engineer tên Minh tin rằng cần đưa vào một message queue. Nhưng team chia làm ba phe: người muốn Kafka, người muốn RabbitMQ, người bảo cứ dùng Redis cho gọn.
Thay vì để ba phe cãi nhau trong stand-up suốt hai tuần, Minh viết một RFC dài 3 trang. Phần Problem nêu rõ con số: đỉnh 1.200 tin nhắn/phút, hiện tại xử lý đồng bộ nên timeout. Phần Alternatives, anh so sánh thẳng thắn: Kafka mạnh về throughput nhưng team chưa ai vận hành được và tốn ~15 triệu/tháng hạ tầng; RabbitMQ đủ dùng, dễ vận hành hơn; Redis rẻ nhưng không đảm bảo message không mất — điều tối kỵ với fintech. Anh đặt RFC mở comment trong 5 ngày và tag CTO làm người quyết định cuối.
Kết quả: trong 5 ngày, một engineer khác chỉ ra rằng nhu cầu thực tế chỉ ~2.000 tin/phút trong 3 năm tới, khiến Kafka trở nên thừa thãi. Team chốt RabbitMQ. Bài học: RFC biến một cuộc tranh cãi cảm tính thành so sánh dựa trên con số, và phần Alternatives viết trung thực đã tự loại bỏ phương án sai lầm mà không cần ai phải "thắng cãi".
Tình huống 2: Cách Stripe dùng RFC để đồng bộ toàn công ty
Stripe nổi tiếng với văn hóa viết. Ở Stripe, khi ai đó muốn thay đổi một API pattern ảnh hưởng đến hàng trăm engineer, họ viết RFC và chia sẻ rộng rãi. Điểm đặc biệt: RFC ở Stripe không chỉ để ra quyết định, mà còn là công cụ lan tỏa kiến thức. Một engineer junior đọc RFC có thể hiểu vì sao hệ thống được thiết kế như hiện tại — thứ mà một buổi họp miệng không bao giờ lưu lại được.
Có một chi tiết đáng học: Stripe khuyến khích tác giả RFC chủ động đi hỏi ý kiến 2–3 người có kinh nghiệm liên quan trước khi mở comment rộng. Cách này giúp lọc bỏ những lỗ hổng lớn sớm, để khi RFC ra công khai nó đã đủ chín để nhận feedback chất lượng thay vì bị "dập" ngay từ vòng đầu. Bài học: RFC không phải là ném tài liệu ra rồi ngồi đợi. Việc "chạy trước" với vài người chủ chốt (thường gọi là pre-review hoặc soft review) làm tăng đáng kể tỉ lệ RFC được chấp nhận và giảm số vòng tranh luận.
Tình huống 3: RFC bị "chết chìm" vì thiếu người quyết định
Một team platform tại một công ty e-commerce lớn ở Đông Nam Á viết RFC đề xuất chuẩn hóa logging trên toàn bộ 40 service. Tài liệu viết rất tốt, thu về hơn 60 comment. Nhưng ba tháng sau, RFC vẫn ở trạng thái "In Review". Không ai dám chốt vì mỗi comment lại mở ra một nhánh tranh luận mới, và không ai được chỉ định rõ là người ra quyết định cuối.
Cuối cùng team mất động lực, mỗi service tự làm logging theo kiểu riêng — đúng cái tình trạng hỗn loạn mà RFC định giải quyết. Bài học: Một RFC không có deadline và không có DRI (Directly Responsible Individual — người chịu trách nhiệm ra quyết định) thì tệ hơn cả việc không có RFC, vì nó tiêu tốn công sức của cả team mà không tạo ra kết quả. Feedback nhiều không đồng nghĩa với quyết định tốt; ai đó phải cân nhắc các ý kiến và dám chốt.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng ngay cho team, dù team lớn hay nhỏ:
Bước 1 — Xác định RFC có thực sự cần thiết. Hỏi: thay đổi này có khó đảo ngược, tốn kém, hay ảnh hưởng nhiều người không? Nếu không, đừng viết RFC — cứ làm và thông báo ngắn gọn.
Bước 2 — Bắt đầu bằng vấn đề, không phải giải pháp. Viết phần Problem thật rõ trước. Nếu bạn không diễn đạt được nỗi đau bằng con số hoặc ví dụ cụ thể, có thể vấn đề chưa đủ chín để đề xuất giải pháp.
Bước 3 — Viết bản Draft. Dùng template có sẵn của công ty (hoặc cấu trúc 7 phần ở trên). Giữ ngắn gọn — 2–4 trang thường là đủ. RFC dài 15 trang thường không ai đọc hết.
Bước 4 — Soft review với 2–3 người liên quan. Gửi riêng cho vài người có kinh nghiệm hoặc bị ảnh hưởng nhiều nhất. Sửa những lỗ hổng lớn trước khi công khai.
Bước 5 — Mở comment với deadline rõ ràng. Chia sẻ rộng qua kênh phù hợp (thường là link tài liệu trên Notion/Google Docs/GitHub PR), nêu rõ: "Mở comment đến hết thứ Sáu, người quyết định cuối là anh X." Thời gian hợp lý thường 3–7 ngày.
Bước 6 — Trả lời từng comment một cách xây dựng. Đừng phòng thủ. Với mỗi phản biện hợp lý, hoặc cập nhật tài liệu, hoặc giải thích vì sao giữ nguyên. Việc bạn phản hồi tử tế quan trọng ngang việc đề xuất đúng.
Bước 7 — Chốt và cập nhật trạng thái. Người DRI ra quyết định, ghi rõ Accepted/Rejected và lý do. Cập nhật trạng thái tài liệu để bất kỳ ai đọc sau này đều biết kết cục.
Bước 8 — Lưu trữ. Giữ RFC ở nơi có thể tìm lại được. Sáu tháng sau khi ai đó hỏi "tại sao chúng ta chọn RabbitMQ?", câu trả lời đã nằm sẵn ở đó.
Lỗi thường gặp & mẹo
Lỗi 1 — Viết RFC như một bài quảng cáo. Người mới thường chỉ ca ngợi giải pháp của mình và bỏ qua nhược điểm. Reviewer tinh ý sẽ mất niềm tin ngay. Mẹo: luôn viết phần Trade-offs trung thực — nêu rõ giải pháp của bạn dở ở điểm nào. Điều này làm tăng, chứ không giảm, độ tin cậy.
Lỗi 2 — Bỏ qua phần Alternatives. Nếu bạn không liệt kê các phương án đã cân nhắc, reviewer sẽ nghĩ bạn chưa suy nghĩ kỹ, và mỗi người sẽ lần lượt hỏi "sao không dùng X?". Mẹo: liệt kê 2–3 phương án khác kèm lý do loại bỏ. Điều này tiết kiệm cả chục vòng comment.
Lỗi 3 — Không đặt deadline. RFC không deadline sẽ trôi nổi vô tận. Mẹo: luôn ghi ngày đóng comment và tên người quyết định ngay trên đầu tài liệu.
Lỗi 4 — Viết quá dài, quá chi tiết. Một RFC 20 trang với sơ đồ class chi tiết thường bị bỏ qua. Mẹo: RFC là để bàn về hướng đi, không phải bản thiết kế cuối cùng. Chi tiết triển khai để dành cho design doc sau khi RFC được chấp nhận.
Lỗi 5 — Phòng thủ khi bị phản biện. Coi comment là công kích cá nhân sẽ giết chết văn hóa RFC. Mẹo: nhớ rằng mục tiêu là ra quyết định tốt nhất cho team, không phải bảo vệ cái tôi. Một câu "Ý này hay, mình đã cập nhật vào phần Risks" tạo dựng uy tín nhanh hơn bất cứ điều gì.
Mẹo văn hóa: Đừng ép áp dụng RFC cho mọi thứ ngay lập tức. Bắt đầu bằng một RFC cho quyết định lớn tiếp theo, làm cho nó thành công, rồi để văn hóa lan ra tự nhiên. RFC chỉ hiệu quả khi cả team thực sự tin vào giá trị của việc viết và phản biện, không phải khi nó bị áp đặt như một thủ tục.
Bài tập thực hành
Bài 1 — Nhận diện. Liệt kê 3 quyết định kỹ thuật gần đây trong team bạn (hoặc dự án cá nhân). Với mỗi cái, đánh giá: đó là "cửa một chiều" hay "cửa hai chiều"? Cái nào lẽ ra xứng đáng có một RFC?
Bài 2 — Viết một RFC mini. Chọn một thay đổi có thật bạn muốn đề xuất (ví dụ: chuyển sang một thư viện mới, thêm cache layer). Viết một RFC 1 trang gồm đủ: Summary, Problem, Proposed Solution, và ít nhất 2 Alternatives kèm lý do loại bỏ. Đặt giới hạn thời gian 30 phút để rèn thói quen viết ngắn gọn.
Bài 3 — Đóng vai reviewer. Lấy RFC mini ở Bài 2, tự đọc lại như một reviewer khó tính và viết ra 3 câu hỏi phản biện sắc bén nhất bạn có thể nghĩ ra. Sau đó cập nhật tài liệu để trả lời trước 3 câu đó. Đây chính là kỹ năng "soft review với chính mình".
Bài 4 — Đề xuất template. Nếu team bạn chưa có template RFC, hãy soạn một template gồm 7 phần đã học và chia sẻ với tech lead. Chỉ riêng hành động này đã có thể nâng chất lượng ra quyết định của cả team.
Tóm tắt
RFC (Request for Comments) là công cụ để tech team suy nghĩ cùng nhau về một thay đổi kỹ thuật lớn trước khi xây dựng, thông qua một tài liệu viết mời cả team phản biện. Nó khác với ADR (ghi lại quyết định đã chốt) và code review (bàn về code cụ thể): RFC nằm ở tầng đề xuất và thuyết phục.
Những điểm cần khắc cốt:
- Chỉ dùng RFC cho quyết định khó đảo ngược, tốn kém, hoặc ảnh hưởng nhiều team — không phải cho mọi thứ.
- Cấu trúc tốt luôn có Problem rõ ràng, Alternatives trung thực, và Trade-offs thành thật — đây là thứ phân biệt RFC trưởng thành với "quảng cáo giải pháp".
- Luôn có deadline và một người quyết định cuối (DRI), nếu không RFC sẽ chết chìm.
- Chạy soft review với vài người chủ chốt trước khi mở comment rộng để tăng chất lượng.
- Đón nhận phản biện với thái độ xây dựng — mục tiêu là quyết định tốt nhất, không phải bảo vệ cái tôi.