RFC Template
Structure architectural change proposals for collaborative discussion and documented decision-making.
Context
You are proposing a major architectural change. Use RFC (Request for Comments) format to solicit feedback, document rationale, and create audit trail. Read existing architecture, team concerns, and alternatives.
Domain Context
Based on RFC processes (Rust RFCs, Internet RFCs):
- Problem Statement: What's broken? Why change? Quantify impact (latency, cost, developer productivity).
- Proposed Solution: How does RFC solve problem? What's the mechanism?
- Detailed Design: Implementation details. APIs, data structures, state management. Enough to review feasibility.
- Alternatives Considered: What else did you think about? Why choose this one?
- Drawbacks and Risks: What could go wrong? Performance impact? Operational complexity? Compatibility issues?
Instructions
RFC Header:
- Title: "Migrate from Monolith to Microservices"
- Status: Draft/Discussion/Approved/Implemented
- Author(s)
- Date
- Related Issues/PRs
Problem Section:
- Current state: Monolithic Node.js app, 500K LOC, hard to test, deploy, scale
- Pain points: 20-minute builds, deployments block all teams, scaling one service scales everything
- Impact: 2 hours/week lost to build/deploy, 1 outage/quarter from scaling issues
Proposed Solution:
- Split into services: API Gateway, Auth, Payment, Orders, Notifications
- Each service: independent repo, CI/CD, database, deployment
- Communication: REST APIs, async via RabbitMQ for events
Design Details:
- Service boundaries (business domain alignment)
- API contracts (OpenAPI specs)
- Data consistency model (eventual consistency between services)
- Deployment strategy (phased, start with payment service)
Alternatives:
- Monolith + horizontal scaling: Cheaper short-term, doesn't solve coupling
- Plugins/modular monolith: Simpler than microservices, still shared deployment
Anti-Patterns
- RFC Too Late: Propose RFC after implementation started. Result: feedback ignored, decision already made. Guard: RFC before coding; treat as discussion forum.
- Vague Proposal: "Move to microservices" without design. Result: unclear feasibility. Guard: Enough detail to assess technical viability.
- Ignoring Feedback: RFC approved but objections recorded. Result: resentment, sabotage. Guard: Address all concerns; if not addressed, document why; build consensus.
- No Implementation Plan: Approve RFC, then surprise team with work. Result: chaos. Guard: RFC includes timeline, resource allocation, rollback plan.
Further Reading
- Rust RFC Process — open RFC governance model
- Architecture Decision Records by Michael Nygard — lightweight decision documentation
- Communicating Design by Dan Brown — presenting proposals effectively
1---2name: rfc-template3description: Propose architectural changes with comprehensive RFCs. Structure feedback, document decisions, track rationale. Use when proposing major architecture changes or design patterns.4---56# RFC Template78Structure architectural change proposals for collaborative discussion and documented decision-making.910## Context1112You are proposing a major architectural change. Use RFC (Request for Comments) format to solicit feedback, document rationale, and create audit trail. Read existing architecture, team concerns, and alternatives.1314## Domain Context1516Based on RFC processes (Rust RFCs, Internet RFCs):1718- **Problem Statement**: What's broken? Why change? Quantify impact (latency, cost, developer productivity).19- **Proposed Solution**: How does RFC solve problem? What's the mechanism?20- **Detailed Design**: Implementation details. APIs, data structures, state management. Enough to review feasibility.21- **Alternatives Considered**: What else did you think about? Why choose this one?22- **Drawbacks and Risks**: What could go wrong? Performance impact? Operational complexity? Compatibility issues?2324## Instructions25261. **RFC Header**:27 - Title: "Migrate from Monolith to Microservices"28 - Status: Draft/Discussion/Approved/Implemented29 - Author(s)30 - Date31 - Related Issues/PRs32332. **Problem Section**:34 - Current state: Monolithic Node.js app, 500K LOC, hard to test, deploy, scale35 - Pain points: 20-minute builds, deployments block all teams, scaling one service scales everything36 - Impact: 2 hours/week lost to build/deploy, 1 outage/quarter from scaling issues37383. **Proposed Solution**:39 - Split into services: API Gateway, Auth, Payment, Orders, Notifications40 - Each service: independent repo, CI/CD, database, deployment41 - Communication: REST APIs, async via RabbitMQ for events42434. **Design Details**:44 - Service boundaries (business domain alignment)45 - API contracts (OpenAPI specs)46 - Data consistency model (eventual consistency between services)47 - Deployment strategy (phased, start with payment service)48495. **Alternatives**:50 - Monolith + horizontal scaling: Cheaper short-term, doesn't solve coupling51 - Plugins/modular monolith: Simpler than microservices, still shared deployment5253## Anti-Patterns5455- **RFC Too Late**: Propose RFC after implementation started. Result: feedback ignored, decision already made. **Guard**: RFC before coding; treat as discussion forum.56- **Vague Proposal**: "Move to microservices" without design. Result: unclear feasibility. **Guard**: Enough detail to assess technical viability.57- **Ignoring Feedback**: RFC approved but objections recorded. Result: resentment, sabotage. **Guard**: Address all concerns; if not addressed, document why; build consensus.58- **No Implementation Plan**: Approve RFC, then surprise team with work. Result: chaos. **Guard**: RFC includes timeline, resource allocation, rollback plan.5960## Further Reading6162- _Rust RFC Process_ — open RFC governance model63- _Architecture Decision Records_ by Michael Nygard — lightweight decision documentation64- _Communicating Design_ by Dan Brown — presenting proposals effectively
sethdford