RFC (Request for Comments) é o formato canônico de proposta técnica desde a IETF nos anos 60. Google, Stripe, Cloudflare, Square — todos operam com cultura de RFC para mudanças técnicas significativas. O ato de escrever força articulação de alternativas e trade-offs; o ato de revisar distribui conhecimento institucional. O documento se torna o registro do processo de decisão — útil para quem chega depois e quer entender por que o sistema é assim.
Template
# RFC-NNN: [Título descritivo]
**Author:** [seu nome]
**Reviewers:** [@person1, @person2, ...]
**Status:** Draft / In Review / Approved / Implemented / Rejected
**Created:** [YYYY-MM-DD]
**Última atualização:** [YYYY-MM-DD]
## TL;DR
[3-5 frases. Problema, solução escolhida, principal trade-off.
Para quem só vai ler isso.]
## Contexto e motivação
[Por que essa mudança é necessária? Qual o estado atual? Que
problema isso resolve? Qual o custo de não fazer?]
### Objetivos
- [O que esta proposta deve alcançar]
- [Métrica/outcome esperado]
### Não-objetivos
- [O que NÃO está sendo proposto, para evitar escopo virar
discussão paralela]
## Alternativas consideradas
### Opção A: [Nome] (RECOMENDADA)
[Descrição em alto nível]
**Prós:**
- [...]
**Contras:**
- [...]
**Esforço estimado:** [X engenheiro-semanas]
### Opção B: [Nome alternativo]
[Descrição]
**Prós:**
- [...]
**Contras:**
- [...]
### Opção C: Status quo (não fazer nada)
**Prós:** zero esforço, zero risco de execução
**Contras:** [problema persiste, oportunidade perdida]
## Proposta detalhada (Opção A)
### Arquitetura proposta
[Diagrama. Componentes. Como interagem.]
### Mudanças nos contratos
- API: [endpoints novos, breaking changes]
- Schema do banco: [migrations necessárias]
- Eventos: [eventos novos publicados/consumidos]
### Plano de implementação
- **Fase 1:** [escopo + prazo]
- **Fase 2:** [escopo + prazo]
- **Fase 3 (rollout):** [estratégia — feature flag, canary, etc.]
### Migration / backward compatibility
[Como vamos migrar dado/clientes existentes? Há janela de
coexistência? Quando o legado morre?]
### Observabilidade
- Métricas a adicionar: [...]
- Logs estruturados: [...]
- Alertas: [...]
- SLOs afetados: [...]
## Considerações
### Performance
[Latência esperada, throughput, escalabilidade. Benchmarks se
aplicável.]
### Segurança
[Threat model link. Considerações de auth, autorização, dados
sensíveis.]
### Confiabilidade
[Failure modes. Backpressure. Circuit breakers. Retries.]
### Custo
[Custo de infra adicional. Custo operacional ongoing.]
### Riscos
| Risco | Probabilidade | Mitigação |
|-------|---------------|-----------|
| [...] | [...] | [...] |
## Open questions
- [Decisões em aberto que precisam de input antes de aprovar]
## Apêndice
- [Links para benchmarks, papers, código de protótipo]
RFC bom inclui a opção "não fazer nada" como alternativa legítima. Forçar essa comparação revela quando a proposta está sendo feita por inércia ou modismo, não por necessidade real. Se fazer-nada perde claramente, a proposta tem força.
Referências
- Pragmatic Engineer — RFCs and Design Docs at Big Tech
- Rust RFC repo (exemplo de processo público)
- Malte Ubl — Design Docs at Google
- Stripe Engineering Blog — vários posts sobre cultura de RFC