Technical RFC Là Gì
Request for Comments (RFC) là document chính thức đề xuất một thay đổi kỹ thuật lớn trong hệ thống, yêu cầu feedback từ stakeholders trước khi triển khai. Khác với ADR (ghi lại quyết định đã đưa ra), RFC là cơ chế thu thập ý kiến trước khi quyết định.
Khi nào cần RFC:
- Thay đổi ảnh hưởng nhiều services hoặc teams
- Migration lớn (database, framework, infrastructure)
- Thêm dependency mới significant (message broker, cache layer)
- Thay đổi API contract public
- Bất kỳ thay đổi nào cần hơn 2 sprints để implement
Khi nào KHÔNG cần RFC:
- Bug fixes, refactoring nhỏ trong 1 service
- Dependency updates (minor/patch)
- Thay đổi đã có precedent rõ ràng (đã có RFC tương tự approved)
RFC Template
markdown# RFC-{NUMBER}: {TITLE}
## Metadata
- **Author:** Tên (role)
- **Created:** YYYY-MM-DD
- **Status:** Draft | In Review | Approved | Rejected | Withdrawn
- **Reviewers:** Danh sách người cần review
- **Target completion:** YYYY-MM-DD
## 1. Problem Statement
Mô tả vấn đề hiện tại. Bao gồm:
- Pain points cụ thể (data, metrics nếu có)
- Impact lên business/team nếu không giải quyết
- Scope: hệ thống/team nào bị ảnh hưởng
## 2. Proposed Solution
Giải pháp đề xuất chi tiết:
- High-level architecture/design
- Components thay đổi
- Data flow mới
- API changes (nếu có)
- Diagrams minh hoạ
## 3. Alternatives Considered
| Alternative | Pros | Cons | Why Not |
|--------------------|-------------------|--------------------|--------------------|
| Option A | ... | ... | ... |
| Option B | ... | ... | ... |
## 4. Risks and Mitigations
| Risk | Probability | Impact | Mitigation |
|--------------------|-------------|--------|--------------------|
| Risk 1 | High/Med/Low| H/M/L | Giải pháp giảm rủi ro |
## 5. Implementation Plan
- Phase 1: ... (timeline)
- Phase 2: ... (timeline)
- Rollback plan
## 6. Success Metrics
- Metric 1: target value
- Metric 2: target value
## 7. Open Questions
- [ ] Câu hỏi chưa có câu trả lời
RFC Lifecycle
Draft ──→ In Review ──→ Approved ──→ Implemented
│ │ │
│ ▼ │
│ Revision │
│ (update & │
│ re-review) │
▼ ▼
Withdrawn Superseded (bởi RFC mới)
Rejected (ghi rõ lý do)
Chi tiết từng phase
Draft (1-3 ngày)
- Author viết RFC, có thể nhờ 1-2 người trusted review sớm
- Chưa share rộng, focus vào completeness
In Review (3-5 business days)
- Share với tất cả required reviewers
- Mở discussion trên PR hoặc dedicated channel
- Author phải respond mọi comment trong 24h
- Nếu có major concern → chuyển lại Draft để revise
Approved
- Majority reviewers approve, không có blocking concern
- Tech Lead hoặc Architecture Board sign off
- Tạo ADR tương ứng ghi lại decision
- Tạo implementation tickets
Rejected/Withdrawn
- Ghi rõ lý do reject vào RFC - đây là knowledge quý giá
- Không xoá RFC, giữ lại làm reference
Review Process
Ai nên review
| Role | Responsibility |
|---|---|
| Tech Lead/Architect | Alignment với overall architecture, standards |
| Senior Devs (affected teams) | Feasibility, implementation concerns |
| DevOps/SRE | Infrastructure, deployment, monitoring impact |
| Product Owner | Business alignment, priority, timeline |
| Security Engineer | Security implications (nếu có) |
Quy tắc review hiệu quả
- Reviewer phải cụ thể - "Tôi lo lắng về X" thay vì "Tôi không thích"
- Phân loại feedback:
- Blocking - phải giải quyết trước khi approve
- Non-blocking - suggestion, có thể address sau
- Question - cần clarification, không phải objection
- Đặt deadline review - quá 5 ngày không respond = implicit approval
- Sync meeting nếu cần - khi async discussion đi vào bế tắc, tổ chức 30-min meeting
Example RFC: Monolith to Microservices Migration
markdown# RFC-007: Tách Order Management thành Microservice
## Metadata
- **Author:** Minh Nguyen (Tech Lead)
- **Created:** 2025-06-01
- **Status:** Approved
- **Reviewers:** Huy (Senior BE), Lan (DevOps), Tung (PO)
- **Target completion:** 2025-09-30
## 1. Problem Statement
Order Management module trong monolith hiện tại:
- **Deployment coupling:** mỗi lần deploy order logic phải deploy
toàn bộ monolith (45 phút downtime window)
- **Scale bottleneck:** order processing cần scale independent,
hiện tại phải scale cả monolith (tốn 3x resource)
- **Team blocking:** 2 teams cùng modify monolith, merge conflict
trung bình 8 lần/sprint, mỗi lần mất 2-4h resolve
- **Database contention:** order table bị lock contention với
reporting queries, gây timeout 15 lần/ngày peak
## 2. Proposed Solution
Tách Order Management thành standalone microservice:
### Architecture
- **Order Service** (.NET 8, minimal API)
- **Database:** PostgreSQL riêng (tách khỏi shared SQL Server)
- **Communication:** RabbitMQ cho async events, gRPC cho sync calls
- **API Gateway:** YARP reverse proxy route traffic
### Data Migration Strategy
- Strangler Fig pattern: route dần traffic sang service mới
- Dual-write period: 2 tuần ghi cả 2 database
- Shadow mode: so sánh kết quả trước khi cutover
## 3. Alternatives Considered
| Alternative | Pros | Cons | Why Not |
|-------------|------|------|---------|
| Modular monolith | Ít risk hơn, deploy cùng unit | Không giải quyết independent scaling | Chưa đủ cho traffic growth 2026 |
| Full microservices migration | Giải quyết triệt để | Quá lớn, 12+ tháng | Risk cao, team chưa đủ experience |
| Vertical slice (order + inventory) | Giải quyết coupling 2 modules | Scope lớn hơn cần thiết | Tăng risk, inventory chưa critical |
## 4. Risks and Mitigations
| Risk | Probability | Impact | Mitigation |
|------|------------|--------|------------|
| Data inconsistency khi dual-write | Medium | High | Reconciliation job chạy mỗi 5 phút |
| Network latency tăng | Low | Medium | gRPC + connection pooling + circuit breaker |
| Team thiếu microservice experience | Medium | Medium | Training 2 tuần trước khi bắt đầu |
| Rollback nếu thất bại | Low | High | Giữ monolith hoạt động song song 1 tháng |
## 5. Implementation Plan
- **Phase 1 (Sprint 1-2):** Setup service skeleton, CI/CD, database
- **Phase 2 (Sprint 3-4):** Migrate read operations (shadow mode)
- **Phase 3 (Sprint 5-6):** Migrate write operations (dual-write)
- **Phase 4 (Sprint 7):** Cutover, decommission monolith module
- **Rollback plan:** Toggle feature flag → route lại về monolith
## 6. Success Metrics
- Deployment time: 45 min → < 5 min
- Independent scaling: order service scale 0 → 10 pods
- Merge conflicts: giảm 80%
- Database timeout: giảm 95%
## 7. Open Questions
- [x] Security: JWT propagation giữa services → dùng shared key
- [x] Monitoring: distributed tracing tool → đã có Jaeger
- [ ] Cost estimate cho additional infrastructure
Tips Viết RFC Hiệu Quả
Nội dung
- Bắt đầu bằng WHY - problem statement phải có data/metrics cụ thể
- Alternatives phải fair - đừng "strawman" options khác để solution của bạn thắng
- Explicit trade-offs - reviewer tin tưởng hơn khi thấy bạn acknowledge nhược điểm
- Diagrams > text - sequence diagram, architecture diagram truyền tải nhanh hơn
Process
- Socialize trước - discuss informal với key stakeholders trước khi viết formal RFC
- Đừng quá dài - 3-5 trang là ideal, thêm appendix nếu cần detail
- Iterate nhanh - address feedback ngay, đừng để RFC kéo dài hơn 2 tuần review
- Document outcome - sau khi approve/reject, tạo ADR tương ứng
Anti-patterns cần tránh
- RFC chỉ có 1 option (thực chất là announcement, không phải RFC)
- Không có rollback plan cho thay đổi lớn
- Problem statement quá vague ("hệ thống chậm" → chậm ở đâu, bao nhiêu?)
- Skip review vì "gấp" - technical debt từ rushed decisions tốn hơn nhiều