Skip to main content
Architecture9 min read

La Decisión de Arquitectura Que Nadie Documenta

Pasamos semanas eligiendo entre Kafka y RabbitMQ pero nunca documentamos por qué. Las ADR toman 15 minutos y ahorran meses de conversaciones de '¿por qué hicimos esto?'.

Part ofProduct Systems->
By Jason TeixeiraDecember 20, 2025
ArchitectureDocumentationADRDecision MakingBest Practices
Share:
On this page

Hace seis meses, elegí Supabase en lugar de Firebase para Nexural. Tenía buenas razones — PostgreSQL, seguridad a nivel de fila, auto-alojable. Pero casi olvido esas razones. Lo único que me salvó de reevaluar la misma decisión (y perder una semana) fue un archivo markdown que escribí en 15 minutos.

El Problema

Todo equipo de ingeniería tiene esta conversación:

"¿Por qué usamos RabbitMQ en lugar de Kafka?" "Creo que Dave lo eligió. Dave se fue hace 8 meses." "..." "¿Deberíamos cambiarnos a Kafka?"

Y ahora estás gastando un sprint reevaluando una decisión que ya fue evaluada. El conocimiento institucional se fue por la puerta.

Registros de Decisiones de Arquitectura (ADR)

Un ADR es un documento breve que captura una decisión significativa. Los míos son extremadamente simples:

\\

Reader route

article -> proof -> offer

ReadClusterProofScope

cluster

Product Systems

intent

Architecture

route

next step

What to do with this

Turn the note into a build path.

If this topic maps to a real business problem, keep reading the cluster, study the academy path, or route the work into a scoped engagement.

Jason Teixeira
Written by
Jason Teixeira
Founder, Sage Ideas Studio · Principal Engineer
livebuild 5d6c8652026-08-05 06:00Z
// solo studio// no analytics resold// every commit human-reviewed