PREMIUM

Template per Technical Design Doc / RFC

Per staff e senior engineer che devono far approvare una scelta architetturale: produce un RFC rigoroso con almeno tre opzioni confrontate su criteri pesati, una decisione motivata e una sezione rischi onesta, pronto per la review del team.

#design-doc #rfc #architettura #decisioni-tecniche #trade-off

Scarica il template Gratis con la registrazione Compila con i tuoi dati

Esempio di output

# RFC-014: Strategia di caching per il catalogo prodotti
Autore: [nome] | Stato: In review | Data: 2026-06-10

## 1. Contesto e problema
Il listing prodotti fa 1.2M query/giorno al DB primario; p95 a 480ms in picco. Serve ridurre il carico senza dati stantii oltre 60s.

## 2. Obiettivi e non-obiettivi
Obiettivi: p95 < 150ms; -60% query al primario; freshness <= 60s.
Non-obiettivi: caching delle pagine checkout; CDN edge.

## 3. Opzioni considerate
### A) Cache in-process (per-istanza)
### B) Redis condiviso con invalidazione su evento
### C) Non fare nulla / scalare il DB in lettura

## 4. Confronto (criteri pesati)
| Criterio (peso) | A | B | C |
|-----------------|---|---|---|
| Latenza (x3) | 4 | 5 | 2 |
| Freshness (x3) | 2 | 5 | 5 |
| Costo infra (x2) | 5 | 3 | 1 |
| Complessita (x2) | 5 | 2 | 5 |
| TOTALE pesato | 38 | 41 | 30 |

## 5. Decisione
Scegliamo B (Redis + invalidazione su evento). Vince per latenza+freshness; accettiamo maggiore complessita operativa.
Contro accettati: nuovo punto di guasto (Redis), serve runbook di failover.

## 6. Rischi e mitigazioni
| Rischio | Prob | Impatto | Mitigazione |
|---------|------|---------|-------------|
| Cache stampede al cold start | Media | Alto | Lock + early recompute |
| Drift invalidazione | Media | Medio | TTL di sicurezza 120s |

## 7. Rollout e metriche
Fase 1: shadow read 5% traffico. Fase 2: 50%. Fase 3: 100%.
Metriche: p95 latenza, hit ratio, query/s al primario. Rollback: feature flag off.

## 8. Domande aperte
- Chi possiede il runbook Redis? 
- TTL definitivo da validare con dati reali.

Domande frequenti

Serve per microservizi e infra o anche per scelte piccole?

Funziona per qualsiasi decisione tecnica non banale: scelta di un database, design di un'API, strategia di migrazione, introduzione di una coda, refactoring architetturale. La profondita delle sezioni si adatta allo scope che indichi in input.

Come fa a non essere di parte verso una soluzione?

Il formato impone almeno tre opzioni (inclusa l'opzione 'non fare nulla') confrontate su una tabella di criteri pesati. I constraints vietano di gonfiare i pro dell'opzione preferita e obbligano a dichiarare i contro di quella scelta. Le assunzioni non verificate vanno elencate esplicitamente.

Include un piano per portare la decisione in produzione?

Si: ogni RFC termina con rollout incrementale, metriche di successo, piano di rollback e domande aperte da risolvere prima dell'implementazione, cosi il documento e davvero approvabile e non solo descrittivo.

Vuoi un template su misura?

Costruiscine uno in poche domande — con la struttura corretta per il tuo standard.

Crea il tuo template