# El arquitecto es una forma de pensar Curso exprés de arquitectura de software. 31 conceptos — Trade-offs, Technical Debt, Coupling, Single Source of Truth, Idempotency, ADR, C4 y más — cada uno con su nombre canónico, una imagen de la vida real, un diagrama y una ficha. Nueve capítulos sobre cómo mirar un problema en el que la decisión de hoy define los próximos tres años. Al final, una hoja de referencia de una página con todos los conceptos. - **Author:** Fedor Chishchin - **Level:** intro - **Reading time:** ~35 minutos de lectura - **Published:** 2026-05-12 - **Source:** https://fedorthinks.com/es/learn/software-architect-express --- ## 1. La mentalidad del arquitecto Lo que separa al arquitecto del ingeniero. No es conocimiento — es una manera de ver el problema. ### Mapa del curso: 31 conceptos en ocho grupos > Un mapa del metro: primero ves todas las líneas juntas, luego viajas estación por estación. La arquitectura no es un conjunto de tecnologías — es un conjunto de **preguntas que se hacen antes de escribir código**. Cada pregunta tiene su propio nombre en la industria: **Trade-offs**, **Coupling**, **Idempotency**, **ADR**. El curso las reúne en ocho grupos — los capítulos 1–8 los siguen. _Diagram: Ocho grupos de conceptos — los capítulos 1–8 los siguen._ ### Cómo leer este curso > Un pasaporte: todos tienen los mismos campos, así que es fácil compararlos. Cada concepto recibe el mismo trato: su **nombre canónico** (recuérdalo — es el término que vas a buscar y por el que te van a preguntar en entrevistas), una imagen de la vida real, un **diagrama** y una **ficha** con campos: _qué es_, _por qué_, _ejemplo_, _trampa_ (dónde suele equivocarse la gente) y conceptos _relacionados_. Cada capítulo termina con su pregunta clave; el curso termina con listas de verificación y una hoja de referencia. ### Problem Framing — cuestiona la tarea, no solo la solución > Un paciente entra al consultorio pidiendo una receta. El buen médico primero pregunta qué le duele — y puede descubrir que el remedio pedido habría sido un error. Cuando alguien dice «haz X», el ingeniero pregunta «cómo hago X». El arquitecto pregunta **«para qué hace falta X, y si otra cosa resolvería el problema real»**. Eso es **problem framing**. Con frecuencia la tarea está mal planteada — y la solución que alguien encargó se vuelve, un año después, el problema. _Diagram: Primero «¿por qué?», luego el problema real, luego las opciones — incluida «no hacer nada»._ #### Problem Framing (encontrar el problema real) - **Qué es:** Encontrar el problema real detrás de un pedido antes de construir una solución. - **Por qué:** El error más caro es construir lo equivocado a la perfección. - **Ejemplo:** Te piden «agregar una exportación a Excel». Preguntas para qué — resulta que a la gente le cuesta usar el informe dentro del sistema. Arregla el informe. - **Trampa:** Saltar directo al «cómo» sin preguntar «por qué». - **Relaciones:** Produce las opciones para **Trade-offs**; «no hacer nada» suele ser la respuesta de **YAGNI**. ### Long-term Thinking — un horizonte de años, responsabilidad por las consecuencias > Un ingeniero construye una casa para la familia que se muda el sábado. Un arquitecto pregunta: «¿Y cuando tengan el tercer hijo? ¿Y cuando la madre se mude con ellos? ¿Y si quieren alquilar la planta baja?» El ingeniero resuelve **el problema tal como está planteado**. El arquitecto resuelve el problema **tal como se verá dentro de tres años**. Eso significa diseñar capacidades que aún no hacen falta, y dejar fuera, a conciencia, las que suenan elegantes pero nunca se van a usar. > Si el carpintero clava un clavo torcido, lo arregla en un día. Si el arquitecto pone un muro de carga en el lugar equivocado, la casa ya no se rehace — hay que vivir en ella. Por eso el arquitecto responde por **las consecuencias, no por el código**. El error del ingeniero se corrige en una semana. El error del arquitecto la empresa lo paga **durante años** — en deuda técnica, en equipos perdidos, en oportunidades que no se aprovecharon. El arquitecto tiene que pensar _antes de que se escriba la primera línea_, y tener el coraje de frenar el desarrollo si la arquitectura no resiste los requisitos reales. _Diagram: Un error de código se corrige en una semana. Un error de arquitectura se paga durante años._ #### Long-term Thinking (responsabilidad por las consecuencias) - **Qué es:** Juzgar una decisión por cómo vivirá dentro de dos o tres años. - **Por qué:** Los errores de arquitectura son los más caros: se pagan durante años. - **Ejemplo:** Al elegir el esquema de una base de datos, pregunta: «¿Y si tenemos diez veces más clientes? ¿Y si aparece un segundo idioma?» - **Trampa:** Confundir «pensar a futuro» con «construir todo por adelantado». Pensar, sí; construir extras, no. - **Relaciones:** Lo equilibran **Simplicity** y **YAGNI**; ayuda a juzgar la **Reversibility**. > **La pregunta central del arquitecto:** «¿Estamos construyendo siquiera la cosa correcta?» > El ingeniero hace bien la cosa. El arquitecto hace la cosa correcta. ## 2. Trade-offs y decisiones La arquitectura es el arte de elegir qué perder. No existen soluciones perfectas. ### Trade-offs — toda decisión gana algo y pierde algo > La bicicleta es más rápida que caminar, pero te mojas bajo la lluvia. El auto no te moja, pero queda atrapado en el tráfico. El metro no se atasca, pero no te deja en la puerta. Cuando el ingeniero elige una tecnología, suele buscar «la mejor». Es una ilusión. El arquitecto sabe: **cualquier elección es un compromiso sobre varios ejes** — velocidad de desarrollo contra mantenibilidad, simplicidad contra flexibilidad, costo ahora contra costo dentro de tres años. Nombrar los ejes y elegir conscientemente es el trabajo arquitectónico. _Diagram: Una decisión es un punto en varios ejes a la vez. Si ganas por un lado, pierdes por otro._ #### Trade-offs (compromisos) - **Qué es:** Toda elección da algo y quita algo. No existe «lo mejor». - **Por qué:** Un trade-off dicho en voz alta se puede discutir y revisar. Uno oculto, no. - **Ejemplo:** Un servicio gestionado en la nube: rápido para empezar (ganas), pero más caro con volumen y más difícil de dejar (pierdes). - **Trampa:** Buscar «la mejor tecnología» en lugar de la adecuada. - **Relaciones:** Se registra en un **ADR**; una pérdida consciente hoy es **Technical Debt**. ### Simplicity (KISS) — la solución simple casi siempre es la más acertada > Una navaja suiza lo hace todo, y todo mal. Un buen cuchillo corta mejor que todos sus hermanos dentro de la navaja suiza. El ingeniero teme perder un requisito y llena el sistema con todo lo que alguna vez podría hacer falta. El arquitecto sabe: **cada capacidad que nadie usa es un impuesto permanente sobre el desarrollo**. La complejidad se introduce a conciencia, cuando está justificada; por defecto — la solución simple, fácil de cambiar. Este principio se suele llamar **KISS** — _Keep It Simple, Stupid_. _Diagram: A la izquierda pagas por lo que nadie usa. A la derecha añades cosas cuando de verdad hacen falta._ #### Simplicity (KISS, Keep It Simple) - **Qué es:** Por defecto, la solución más simple que resuelva el problema. - **Por qué:** Lo simple es fácil de entender, probar y cambiar. Lo complejo solo se soporta. - **Ejemplo:** ¿Cien tareas en segundo plano al día? Una tabla en la base de datos y cron bastan — no hace falta un message broker aparte. - **Trampa:** Construir «por si acaso»: cada función extra es un impuesto permanente. - **Relaciones:** Hermano de **YAGNI**; abarata la **Evolvability**. ### Reversibility — las decisiones difíciles de deshacer merecen más atención > En un restaurante puedes devolver un plato. Un «sí» en una boda no se devuelve. No todas las decisiones arquitectónicas cuestan lo mismo si resultan erróneas. Elegir un lenguaje de programación o una base de datos es **casi irreversible**. Elegir una biblioteca de logs se revierte en un día. El arquitecto dedica un tiempo desproporcionado a las decisiones irreversibles y avanza rápido en las reversibles. En la industria suelen llamarlas **one-way door** (puerta de un solo sentido) y **two-way door** (puerta de doble sentido). _Diagram: Lo reversible se decide rápido. Lo irreversible, despacio y con el «porqué» por escrito._ #### Reversibility (puerta de un sentido / de dos sentidos) - **Qué es:** Cuánto cuesta deshacer una decisión si resulta errónea. - **Por qué:** El tiempo de reflexión debe ser proporcional al costo de un error. - **Ejemplo:** Una biblioteca de logs — se cambia en un día. La base de datos principal — años de migración. - **Trampa:** Discutir semanas sobre lo reversible y elegir lo irreversible en cinco minutos. - **Relaciones:** Las decisiones irreversibles merecen un **ADR**; una **Interface** y una capa propia sobre las **External Dependencies** vuelven las cosas más reversibles. ### Technical Debt — una elección consciente, no pereza > Un crédito de negocio está bien si sabes cuándo y cómo lo vas a devolver. Un crédito sin plan de pago es el camino a la quiebra. A veces lo correcto _ahora_ es entregar algo que tendrás que reescribir _después_. Eso es **technical debt** (deuda técnica). Y es normal. **Lo que no es normal es no reconocer que es una deuda.** El arquitecto anota qué trade-offs se tomaron, por qué, y cuándo hay que volver a ellos. _Diagram: La deuda registrada se paga según el plan. La deuda sin registrar acumula intereses — el equipo se vuelve más lento cada mes._ #### Technical Debt (deuda técnica) - **Qué es:** Un atajo ahora que pagarás después con una reescritura. - **Por qué:** A veces la velocidad de hoy importa más que la limpieza — un intercambio legítimo. - **Ejemplo:** Antes del lanzamiento se dejó una sola moneda fija en el código. Quedó anotado: «revisar cuando aparezca un segundo mercado». - **Trampa:** Una deuda sin registro: nadie recuerda que existe, y los intereses crecen. - **Relaciones:** Un **Trade-off** registrado en un **ADR**; se paga mediante una **Migration**. > **La pregunta para cada decisión:** «¿Qué estoy eligiendo — y qué estoy perdiendo con ello?» ## 3. Diseño del sistema Cómo descomponer un problema grande en componentes que se puedan entender, cambiar y reemplazar por separado. ### Decomposition — la habilidad central del arquitecto > No puedes comerte una ballena entera. Sí puedes — si la cortas en trozos que te caben en la boca. Un sistema grande es incomprensible. **Decomposition** es la habilidad de cortarlo en partes. **Una buena arquitectura es un conjunto de partes pequeñas, cada una comprensible por sí sola**. Si para explicar un componente hay que traer otros tres — la descomposición es mala. _Diagram: El sistema entero no se puede entender. Las partes que se explican solas, sí._ #### Decomposition (dividir en partes) - **Qué es:** Cortar el sistema en partes, cada una comprensible por sí sola. - **Por qué:** Una persona solo puede tener cierta cantidad en la cabeza. Las partes pequeñas se pueden entender y cambiar. - **Ejemplo:** Una tienda en línea: pedidos, pagos, catálogo, cuentas — cada parte con su propia responsabilidad. - **Trampa:** Cortar por tecnología («todos los controllers aquí») en lugar de por sentido. - **Relaciones:** El corte se mide con **Cohesion & Coupling**; las partes hablan a través de una **Interface**. ### Cohesion & Coupling — alta cohesión por dentro, bajo acoplamiento por fuera > Un buen departamento: la cocina está organizada en torno a un solo propósito (la estufa junto al fregadero) y comparte con los vecinos una sola pared. Dentro de un módulo todo debe tratar **de una sola cosa** — eso es **alta cohesión**. Entre módulos — el mínimo contacto, a través de una interfaz clara — eso es **bajo acoplamiento**. Si cambias algo en un módulo y tienes que tocar otros cinco — el acoplamiento entre ellos es demasiado alto. _Diagram: Izquierda: cada módulo trata de una sola cosa, con un solo vínculo. Derecha: todo mezclado y conectado con todo._ #### Cohesion & Coupling (foco por dentro, pocos vínculos por fuera) - **Qué es:** **Cohesion** — cuánto tratan de una sola cosa las partes de un módulo. **Coupling** — cuánto dependen los módulos entre sí. - **Por qué:** Así un cambio se queda dentro de un módulo en lugar de propagarse como una ola. - **Ejemplo:** El cálculo de impuestos vive en «Facturación», no esparcido entre pedidos, correos e informes. - **Trampa:** «Cambias uno, tocas cinco»: señal clara de alto acoplamiento. - **Relaciones:** La vara de medir de la **Decomposition**; se sostiene con una **Interface**. ### Layers & the Dependency Rule — las capas tratan de la dirección de las dependencias > Los pisos de una casa: el tercero se apoya en el segundo, el segundo en el primero, el primero en los cimientos. No se pueden poner los cimientos sobre el tercer piso. En una buena arquitectura, **la lógica de negocio no sabe nada de la base de datos, la interfaz web ni el framework**. Las capas internas no dependen de las externas — esa es la **dependency rule** (regla de dependencia). Cuando hay que cambiar la base de datos o el framework, la lógica de negocio no se toca. Eso es **Clean Architecture** en una frase. _Diagram: Los detalles (interfaz, base de datos, framework) dependen de la lógica de negocio — nunca al revés._ #### Dependency Rule (capas, Clean Architecture) - **Qué es:** Las dependencias apuntan hacia adentro: los detalles conocen el núcleo, el núcleo no conoce los detalles. - **Por qué:** Puedes cambiar la base de datos o el framework sin tocar las reglas de negocio. - **Ejemplo:** La regla «10 % de descuento por tres artículos» no importa ni SQL ni HTTP — se puede probar sin base de datos. - **Trampa:** Consultas SQL y respuestas HTTP dentro de la propia lógica de negocio. - **Relaciones:** Funciona mediante una **Interface**; se ve a fondo en el curso de patrones de arquitectura (Hexagonal, Clean). ### Interface over Implementation — importa más la interfaz > No te importa qué marca de ascensor hay en el edificio. Te importa que los botones funcionen igual, que las puertas abran con fiabilidad y que sea silencioso. Cuando un módulo habla con otro, lo que importa es **el contrato entre ellos (la interfaz)**, no cómo está construido por dentro el otro (**la implementación**). Primero se diseña la frontera (API, interfaz de clase, esquema de mensajes), luego la implementación. Las implementaciones se cambian con libertad; los contratos, solo siendo plenamente consciente del costo. _Diagram: Quien llama ve solo la interfaz. La implementación detrás se puede reemplazar._ #### Interface over Implementation (primero el contrato) - **Qué es:** Diseñar primero la frontera entre las partes, después su interior. - **Por qué:** La implementación puede cambiar libremente mientras el contrato se mantenga. - **Ejemplo:** Una interfaz `sendEmail(to, text)`: hoy detrás hay un proveedor de correo, mañana otro — el código que la llama no cambia. - **Trampa:** Quien llama mete la mano en las entrañas de otro módulo, saltándose la interfaz. - **Relaciones:** En el borde del sistema, una interfaz se convierte en un **API Contract**; es la base de la **Dependency Rule**. ### Monolith vs Microservices — cuestión de madurez, no de moda > Un cocinero en una cocina pequeña hace un plato más rápido que diez cocineros negociando por Slack. Con cien platos por hora, diez cocineros lo hacen mejor. Un **monolito** es una aplicación que se despliega entera. Los **microservicios** son muchos servicios pequeños, cada uno con su propio despliegue. Los microservicios resuelven problemas de **escala organizativa y de carga**, no de calidad del código. Un equipo pequeño con microservicios es una complejidad que nadie pidió. El arquitecto empieza con un monolito y lo divide cuando aparece dolor real, no «porque está de moda». _Diagram: Empieza con un monolito. Divide cuando de verdad duela: crece el equipo o la carga._ #### Monolith vs Microservices (una app o muchos servicios) - **Qué es:** Una aplicación entera — o muchos servicios separados. - **Por qué:** Los microservicios dan despliegues y escalado independientes a equipos y cargas grandes. - **Ejemplo:** Un equipo de cinco construye un producto — monolito. Veinte equipos que se pisan en un solo despliegue — hora de dividir. - **Trampa:** Microservicios por moda: red, fallos y consistencia sin nada a cambio. - **Relaciones:** Se divide siguiendo la **Decomposition**; luego los servicios necesitan **Sync vs Async** e **Idempotency**. > **Prueba de la descomposición:** «¿Puedo explicar un componente sin mencionar los demás?» ## 4. Datos y estado La parte más duradera del sistema. Los patrones de código se reescriben; el modelo de datos vive años. ### Data Model — sobrevive a todo lo demás > Los cimientos de una casa sobreviven a todas las paredes y tejados que se construyen sobre ellos durante un siglo. Los lenguajes se irán, los frameworks cambiarán, la interfaz se redibujará diez veces. **El modelo de datos que se pone al principio se queda** — porque cambiarlo en un sistema en marcha es carísimo. Es lo primero en lo que el arquitecto invierte tiempo y lo último que se apura a corregir. _Diagram: La interfaz se redibuja muchas veces, el framework y el lenguaje cambian — el modelo de datos se queda._ #### Data Model (entidades, campos, relaciones) - **Qué es:** Qué entidades tiene el sistema, sus campos y relaciones. - **Por qué:** Es la parte que más vive — la más cara de cambiar después. - **Ejemplo:** Decide desde el principio: ¿un pedido tiene una dirección de entrega o varias? Cambiarlo después significa migrar millones de filas. - **Trampa:** Esbozar tablas en una tarde y construir sobre ellas durante años. - **Relaciones:** Dónde vive cada dato — **Single Source of Truth**; cómo cambiarlo — **Migration**. ### Single Source of Truth — cada dato vive en un solo lugar > Si cada miembro de la familia lleva su propia lista de compras, dos comprarán leche y nadie comprará pan. La misma información en dos lugares es **un camino seguro hacia la divergencia**. El principio de **single source of truth (SSOT)**: el arquitecto determina dónde vive cada dato del sistema. Si los datos se duplican (por rendimiento, por ejemplo), debe quedar explícito qué es la fuente de verdad y qué es una caché o una proyección. _Diagram: Las escrituras van solo a la fuente de verdad; la caché, la réplica y la proyección son copias derivadas._ #### Single Source of Truth (SSOT) - **Qué es:** Cada dato tiene un hogar principal; todo lo demás son copias. - **Por qué:** Cuando las copias divergen, está claro en cuál confiar. - **Ejemplo:** El precio de un producto vive en el catálogo. El índice de búsqueda y la caché del sitio son copias, reconstruidas desde el catálogo. - **Trampa:** Dos sistemas que creen ser dueños del mismo campo. - **Relaciones:** Las copias son **Cache** y proyecciones; menos copias — menos **State**. ### State — complejidad; cuanto menos, mejor > Un escritorio despejado facilita el trabajo. Uno desordenado te obliga a recordar dónde está cada cosa y te distrae todo el tiempo. Cada pieza de **estado** guardada en algún lugar es **algo que puede desincronizarse, perderse o contradecir** a otro estado. La buena arquitectura apunta a funciones sin memoria (**stateless**) y variables de vida corta. El estado queda donde de verdad hace falta — normalmente en la base de datos. _Diagram: Las instancias de la app no recuerdan nada — todo el estado vive en un solo lugar, la base de datos._ #### State (stateless vs stateful) - **Qué es:** Todo lo que el sistema recuerda entre peticiones. - **Por qué:** Menos estado — menos lugares donde algo puede divergir o perderse. - **Ejemplo:** El carrito de compras vive en la base de datos, no en la memoria del servidor: el servidor se reinicia — el carrito sobrevive. - **Trampa:** Estado en la memoria de un solo servidor: el servidor muere — los datos desaparecen. - **Relaciones:** Los servicios stateless son fáciles de multiplicar — eso es **Scalability**. ### Transactions — la atomicidad de la intención > Una transferencia de dinero son dos acciones pero una sola intención. O ocurrieron las dos escrituras, o ninguna. A medias es una catástrofe. Cuando varios cambios deben ocurrir **como una sola unidad**, hacen falta **transacciones**. Esa propiedad se llama **atomicidad**. El arquitecto sabe qué operaciones del sistema son atómicas, cuáles pueden fallar a medias y cómo convivir con eso. En los sistemas distribuidos esto se vuelve un problema central (two-phase commit, sagas, idempotency). _Diagram: Las dos escrituras o ninguna. No existe el a medias._ #### Transaction (atomicidad) - **Qué es:** Varios cambios que ocurren por completo o no ocurren. - **Por qué:** De lo contrario el sistema se queda atascado en un estado «a medio hacer». - **Ejemplo:** Una transferencia: débito en A y crédito en B — en una sola transacción. - **Trampa:** Suponer que una transacción abarca varios servicios. Ahí hacen falta sagas e idempotency. - **Relaciones:** Entre servicios se apoya en la **Idempotency**; mira el patrón Saga en el curso de patrones de arquitectura. ### Cache — una segunda verdad, y puede mentir > El calendario del refrigerador es más rápido que mirar el teléfono. Pero si alguien cambió el horario en el teléfono — el refrigerador ya está mintiendo. Una **caché** da velocidad pero quita **la garantía de frescura**. El arquitecto siempre entiende: qué se cachea, por cuánto tiempo y qué pasa si la caché miente. La pregunta más difícil sobre una caché no es cómo agregarla — es _cómo invalidarla_ (**cache invalidation**). _Diagram: La caché responde rápido, pero tras un cambio en la base de datos hay que reiniciarla — si no, miente._ #### Cache (invalidación de caché) - **Qué es:** Una copia rápida de los datos cerca de quien los lee. - **Por qué:** Velocidad y menos carga sobre la fuente. - **Ejemplo:** El precio cambió en la base de datos — la caché aún tiene el viejo. El cliente ve un precio y paga otro. - **Trampa:** Agregar una caché sin decidir cuándo y cómo reiniciarla. - **Relaciones:** Una copia bajo **Single Source of Truth**, no una segunda verdad. > **La pregunta para cualquier dato:** «¿Dónde está la fuente de verdad, y qué pasa si las copias divergen?» ## 5. Conexiones y fronteras Los mayores problemas nacen no dentro de los componentes, sino entre ellos. ### API Contract — la frontera de un sistema es un contrato, no código > La frontera entre países no es una valla — son las reglas: qué se puede cruzar, quién entra, qué pasaporte hace falta. Una API, un esquema de mensajes, un formato de archivo — son **una promesa a todos los que los usan**. Cambiar el contrato es cambiar la promesa, y eso cuesta mucho. Un buen arquitecto diseña los contratos para poder ampliarlos sin romper a los clientes existentes (añadir campos, nunca quitarlos). Esa propiedad se llama **backward compatibility** (compatibilidad hacia atrás). _Diagram: Añades un campo — los clientes viejos siguen vivos. Quitas un campo — los clientes viejos se rompen._ #### API Contract (compatibilidad hacia atrás) - **Qué es:** Una promesa pública: qué peticiones se aceptan y qué se devuelve. - **Por qué:** Dependen de él clientes que no controlas. - **Ejemplo:** Se añadió un campo `currency` a la respuesta — la app vieja simplemente lo ignora. Se renombró `price` — la app vieja se cayó. - **Trampa:** Cambiar el contrato con la misma ligereza que el código interno. - **Relaciones:** El rostro exterior de **Interface over Implementation**; se cambia mediante una **Migration**. ### Sync vs Async — una elección de acoplamiento en el tiempo > Una llamada telefónica: ambos tienen que estar en línea al mismo tiempo. Una carta: el destinatario la lee cuando le conviene. Una llamada **síncrona** **acopla dos servicios en el tiempo**: si el receptor está caído, el emisor también se atasca. La mensajería **asíncrona** a través de una cola rompe ese acoplamiento: el emisor deja la carta y sigue. Eso da resiliencia pero añade complejidad — retrasos, duplicados, orden. _Diagram: Arriba: A espera a B y cae con él. Abajo: A deja un mensaje en una cola y sigue._ #### Sync vs Async (llamada o carta) - **Qué es:** Esperar la respuesta de inmediato (una llamada) — o enviar y no esperar (una carta). - **Por qué:** Async desacopla los servicios: que uno falle no detiene al otro. - **Ejemplo:** Hacer un pedido — síncrono (el cliente espera). El correo con el recibo — asíncrono, mediante una cola. - **Trampa:** Olvidar el precio de async: retrasos, duplicados, mensajes desordenados. - **Relaciones:** Los duplicados exigen **Idempotency**; es habitual entre microservicios. ### Idempotency — una operación se puede repetir sin riesgo > Se llama al ascensor al tercer piso. Si diez personas vuelven a pulsar el mismo botón, el ascensor sigue yendo al tercer piso y no se rompe nada. En los sistemas reales las llamadas se reintentan — por timeouts, fallos de red, reinicios. Una operación **idempotente** da el mismo resultado al repetirse. **Una operación peligrosa de reintentar es una bomba de tiempo.** El arquitecto hace idempotentes por defecto las operaciones críticas (pagos, procesamiento de mensajes). _Diagram: La misma petición llegó tres veces — el dinero se cobró una sola vez._ #### Idempotency (seguro de repetir) - **Qué es:** Repetir una operación da el mismo resultado que ejecutarla una vez. - **Por qué:** Los reintentos son inevitables: timeouts, fallos de red, reinicios. - **Ejemplo:** El cliente envía un pago con una clave única. Llega otra vez la misma clave — el servidor devuelve el resultado anterior en lugar de cobrar de nuevo. - **Trampa:** «Nunca recibimos reintentos» — sí los recibes, solo que aún no los has visto. - **Relaciones:** Necesaria con **Async** y reintentos; un cimiento de la **Reliability**. ### External Dependencies — siempre un riesgo > Si la cena depende de la pizzería de enfrente — no pasa nada, hay alternativas. Si depende del único proveedor de carne de la ciudad — es crítico. Toda **dependencia externa** — API, servicio, biblioteca — **puede caerse, volverse lenta o cambiar su contrato**. El arquitecto decide qué pasará cuando eso ocurra: ¿cae todo el sistema, o sigue funcionando con degradación? Muchas veces conviene aislar la dependencia externa detrás de una capa propia (un **adapter**) — para poder cambiarla después. _Diagram: El núcleo habla con su propio adapter. Detrás: el proveedor, un proveedor de respaldo o un modo degradado._ #### External Dependencies (tu propio adapter) - **Qué es:** Todo lo que no controlas: las API, servicios y bibliotecas de otros. - **Por qué:** Cuando fallan o cambian, tu sistema no debe caer con ellos. - **Ejemplo:** El proveedor de pagos se esconde detrás de tu propia interfaz `PaymentGateway`. Cambiar de proveedor significa un adapter nuevo, no reescribir los pedidos. - **Trampa:** Llamadas al SDK de un proveedor esparcidas por todo el código. - **Relaciones:** Una aplicación de **Interface over Implementation**; parte de la **Reliability** (fallback). > **Prueba de la frontera:** «¿Qué pasa si esta conexión se rompe?» ## 6. Requisitos no funcionales No «qué hace el sistema» sino «qué tan bien lo hace». Se llaman requisitos no funcionales (NFR) o atributos de calidad — lo que el cliente nunca va a formular, pero que exigirá sin falta. ### Security — no es una función, es una forma de vida del sistema > En un museo, la seguridad no es una cámara en la puerta — son capas: torniquetes, guardias, cámaras en cada sala, cerraduras en las vitrinas. La **seguridad** no se puede añadir al final. Se construye en cada capa: **autenticación, autorización, cifrado, aislamiento, auditoría, mínimo privilegio**. Este enfoque por capas se llama **defense in depth**. El arquitecto piensa en ella desde el primer día y en cada decisión pregunta: «¿Y si un atacante entra por aquí?» _Diagram: Defensa por capas: si pasas una, el atacante choca con la siguiente._ #### Security (defense in depth, least privilege) - **Qué es:** Protección en todos los niveles del sistema, no un solo candado en la puerta. - **Por qué:** Tarde o temprano una capa será vulnerada — las demás deben resistir. - **Ejemplo:** El servicio de informes tiene acceso de solo lectura a la base de datos — aunque lo hackeen, no se pueden borrar los datos. - **Trampa:** «Añadiremos la seguridad antes del lanzamiento». - **Relaciones:** La auditoría se apoya en la **Observability**; el aislamiento se apoya en fronteras claras. ### Performance — no «rápido», sino «lo bastante rápido para la carga requerida» > Un taxi para tres personas no debe viajar como un tren bala. Un tren bala no cabe por una calle lateral. «Hazlo rápido» es un requisito sin sentido. El arquitecto expresa el **rendimiento** en números: **cuántas peticiones por segundo (throughput), qué latencia es tolerable, cómo se comporta el sistema en el pico, qué pasa al pasar el límite**. Optimizar demasiado pronto es un desperdicio; no pensar en absoluto es una catástrofe. _Diagram: Un requisito son números: qué latencia es tolerable, con qué carga. Y qué pasa al pasar el límite._ #### Performance (latency, throughput) - **Qué es:** Cuánto maneja el sistema y qué tan rápido responde — en números. - **Por qué:** Sin números no se sabe si alcanza, ni dónde parar. - **Ejemplo:** «La búsqueda responde en menos de 300 ms con 200 peticiones por segundo; en el pico — una cola, no una caída.» - **Trampa:** «Hazlo rápido» sin números — y optimizar lo que no duele. - **Relaciones:** Si crece la carga — **Scalability**; se mide mediante **Observability**. ### Scalability — la capacidad de crecer sin reescribir > Una casa diseñada con la opción de añadir un segundo piso se amplía sin demoler. Una casa sin esa opción — solo reconstruyéndola desde cero. **Scalability**: el sistema debe crecer **en dos direcciones** — más usuarios (**horizontalmente** — añadir servidores) y más funciones (**de forma modular** — añadir módulos sin romper los viejos). Eso se incorpora al diseño, no se añade después. _Diagram: Dos ejes de crecimiento: a la derecha — más servidores, hacia abajo — más módulos._ #### Scalability (horizontal y modular) - **Qué es:** La capacidad de crecer en carga y en funciones sin reescribir. - **Por qué:** Un sistema exitoso crece — reescribirlo sobre la marcha es caro. - **Ejemplo:** Un servicio stateless detrás de un balanceador de carga: subió la carga — añade tres copias más. - **Trampa:** Construir para un millón de usuarios cuando tienes cien. - **Relaciones:** Se apoya en **State** (stateless) y en **Cohesion & Coupling** (módulos). ### Reliability — el comportamiento del sistema cuando algo se rompe > Un buen barco no es el que no se hunde (esos no existen) — es el que tiene diez compartimentos, de modo que si se perfora uno, los demás siguen a flote. Cada parte de un sistema termina por romperse. **Reliability** no es «nunca se rompe» — es «sobrevive a la rotura». El arquitecto no intenta evitar el fallo — **diseña cómo sobrevive el sistema**: **aislamiento de fallos, reintentos, degradación elegante, fallbacks**. La regla principal: _el fallo de un componente no debe matar todo el sistema_. _Diagram: Compartimentos de un barco: una brecha no hunde el resto. Abajo — cuatro tácticas de fiabilidad._ #### Reliability (tolerancia a fallos) - **Qué es:** Cómo se comporta el sistema cuando una parte se ha roto. - **Por qué:** Todo se rompe — la única pregunta es si un fallo arrastra a los demás. - **Ejemplo:** El servicio de recomendaciones cayó — la tienda muestra «lo más popular» en lugar de sugerencias personales, pero sigue vendiendo. - **Trampa:** Construir como si los fallos no fueran a ocurrir. - **Relaciones:** Los reintentos requieren **Idempotency**; la **Observability** permite ver el fallo. ### Observability — no puedes arreglar lo que no ves > Un coche sin indicador de combustible, sin termómetro, sin indicador de presión de aceite. Anda hasta que muere para siempre. **Observability**: el sistema debe **contarte su propio estado** — **logs, métricas, trazas**. Cuando algo sale mal a las tres de la mañana, tienes minutos para encontrar el problema. Si la observabilidad no se diseña desde el principio, ya es tarde para añadirla — ni siquiera sabes dónde mirar. _Diagram: Tres señales — logs, métricas, trazas — convierten una caída nocturna en una búsqueda de minutos._ #### Observability (logs, métricas, trazas) - **Qué es:** La capacidad de entender lo que pasa dentro del sistema a partir de sus señales. - **Por qué:** Sin señales, una caída se busca durante horas, a ciegas. - **Ejemplo:** Una métrica muestra un pico de errores a las 03:00, una traza muestra una API externa lenta, un log muestra qué error. - **Trampa:** Añadir logs después de la primera gran caída. - **Relaciones:** Los ojos de la **Reliability** y la **Performance**; la base de la auditoría en **Security**. > **La pregunta no funcional principal:** «¿Con qué carga, en qué condiciones, con qué fiabilidad?» ## 7. Evolución del sistema Un sistema vive mucho tiempo. Se va a cambiar. La buena arquitectura es la que se cambia con facilidad. ### Evolvability — estar listo para el cambio importa más que tener razón hoy > En una ciudad nueva, las calles se hacen más anchas de lo que hoy hace falta. Diez años después hay más coches, y las calles estrechas habría que levantarlas. El arquitecto no intenta predecir cada función futura (es imposible). **Deja la opción de añadir funciones sin romper lo existente**. Esa propiedad se llama **evolvability**. En la práctica significa: fronteras claras, contratos extensibles, separar el «qué» del «cómo». #### Evolvability (preparación para el cambio) - **Qué es:** Qué tan barato es añadir o cambiar algo en el sistema. - **Por qué:** Los requisitos van a cambiar seguro — lo único que se ignora es cómo. - **Ejemplo:** Un método de pago nuevo se añade como un adapter nuevo, no como ediciones en veinte lugares. - **Trampa:** Intentar adivinar cada función futura y construirla por adelantado. - **Relaciones:** Nace de la **Interface**, de **Cohesion & Coupling**, de un **API Contract** extensible. ### Migration — un problema de primera clase, no «lo haremos después» > Mudarse de una casa vieja a una nueva es un proceso de meses. No puedes tirar todo y volver a comprarlo todo. Cuando un sistema necesita cambiar (nueva base de datos, nuevo protocolo, nuevo modelo de datos) — eso **no es «reescribir desde cero», es «llevar el sistema a través de una transición»**. Eso es una **migration**. Los sistemas reales funcionan durante los cambios. El arquitecto piensa en el camino de la migración desde el principio; si no, la transición se vuelve imposible. _Diagram: Lo viejo y lo nuevo conviven, el tráfico se traslada poco a poco, el sistema nunca se detiene._ #### Migration (periodo de transición) - **Qué es:** Mover un sistema en marcha de lo viejo a lo nuevo — paso a paso. - **Por qué:** Un sistema real no se puede apagar por obras. - **Ejemplo:** Una base de datos nueva: primero se escribe en ambas, luego se lee de la nueva, luego se apaga la vieja. - **Trampa:** «Lo reescribimos desde cero en un trimestre» — y se vive con dos sistemas durante dos años. - **Relaciones:** Cómo cambian el **Data Model** y el **API Contract**; cómo se paga la **Technical Debt**. ### YAGNI & Deletion — borrar importa más que añadir > Un armario no se puede ampliar para siempre. A veces hay que tirar lo viejo para hacer sitio a lo nuevo. Todo sistema exitoso acumula código muerto, funciones sin uso, integraciones obsoletas. **Es un impuesto que cada desarrollador paga todos los días.** El arquitecto se pregunta con regularidad: «¿Qué podemos borrar?» — y a veces esa es la decisión arquitectónica más útil del año. > El muro más fuerte es el que nunca hubo que derribar, porque nada superfluo quedó encajado detrás de él. A veces la decisión arquitectónica correcta es **no tomar una decisión arquitectónica**. No introducir una capa de abstracción «para el futuro». No dividir el monolito «porque algún día». No construir un sistema de plugins «por si acaso». El principio se llama **YAGNI** — _You Aren't Gonna Need It_ (no lo vas a necesitar). Un buen arquitecto sabe cuándo decir «todavía no» o «esto no hace falta». #### YAGNI & Deletion (You Aren't Gonna Need It) - **Qué es:** No construir lo que no hace falta ahora, y borrar lo que ya no hace falta. - **Por qué:** La mejor arquitectura es la que no hizo falta: cuesta cero. - **Ejemplo:** Se borró una integración que usaban dos clientes: menos mil líneas, menos una dependencia, menos alertas nocturnas. - **Trampa:** Abstracciones y plugins «por si acaso». - **Relaciones:** Una extensión de **Simplicity**; libera espacio para la **Evolvability**. > **Prueba de la evolución:** «¿Cuánto código tendría que reescribir si cambiaran los requisitos?» ## 8. Comunicación y documentación Una arquitectura que nadie entiende no existe. La mitad del trabajo es transmitirla. ### ADR — una decisión arquitectónica se anota, o se pierde > Un testamento oral muere con su autor. Uno escrito sobrevive a generaciones. Toda decisión arquitectónica importante debe registrarse: **qué se eligió, cuáles eran las alternativas, por qué se descartaron, qué compromisos se aceptaron**. El documento no hace falta ahora — hace falta dentro de un año, cuando llega una persona nueva y pregunta «¿por qué esto está hecho de una forma tan rara?». El formato estándar es el **ADR (Architecture Decision Record)**. _Diagram: Una página corta por decisión: contexto, elección, alternativas, trade-offs, cuándo revisarla._ #### ADR (Architecture Decision Record) - **Qué es:** Un registro breve de una decisión arquitectónica y sus razones. - **Por qué:** Un año después nadie recuerda el porqué. El registro sí. - **Ejemplo:** «ADR-007: Postgres, no MongoDB. Necesitamos transacciones entre pedido y pago. Coste — un esquema más estricto. Revisar si aparecen datos no estructurados.» - **Trampa:** Escribir solo el «qué», sin el «por qué» ni las opciones descartadas. - **Relaciones:** Contiene **Trade-offs**, **Technical Debt** y decisiones irreversibles. ### C4 Model — un diagrama vale más que mil palabras > Describir con palabras cómo llegar a una casa es largo y a menudo inútil. Mostrar un mapa lleva un segundo. El arquitecto **siempre tiene un diagrama del sistema**: qué componentes hay, cómo se conectan, dónde están las fronteras. No perfecto — funcional. Sirve para explicar rápido a una persona nueva y para ver el sistema entero. El **modelo C4 (Context, Container, Component, Code)** es simple y suficiente para la mayoría de los casos. _Diagram: Cuatro niveles de zoom — como un mapa: país, ciudad, calle, casa._ #### C4 Model (Context · Container · Component · Code) - **Qué es:** Cuatro niveles de diagramas — del sistema entero hasta el código. - **Por qué:** Cada audiencia recibe su propio nivel de zoom, no una sola imagen para todo. - **Ejemplo:** Context: la tienda, el cliente, el proveedor de pagos. Container: app web, API, base de datos, cola. - **Trampa:** Un diagrama gigante donde todo está en un solo nivel y nada se entiende. - **Relaciones:** Dibuja la **Decomposition** y sus fronteras; complementa al **ADR**. ### Stakeholder Communication — explicar a quien no es ingeniero, y saber decir «no» > Un buen médico explica el diagnóstico al paciente con palabras que este entiende. Uno malo usa términos médicos tras los cuales el paciente asiente y no entiende nada. Si el arquitecto solo sabe explicar una decisión a otros ingenieros, **se ha perdido la mitad del trabajo**. Negocio, producto, legal, seguridad — todos los **stakeholders** necesitan entender las consecuencias. Traducir una decisión técnica al lenguaje del negocio (**costo, riesgo, tiempo**) es una de las habilidades centrales del arquitecto. > Un cirujano que acepta todas las peticiones pierde pacientes. Uno bueno se niega cuando la operación mataría. El equipo a menudo pide decisiones que suenan razonables pero crean problemas a largo plazo. **El arquitecto tiene que saber negarse, explicar el riesgo y a veces mantener su postura** — aunque sea impopular. Y también — saber admitir que se equivoca y cambiar la decisión cuando el contraargumento es más fuerte. #### Stakeholder Communication (explicar y decir «no») - **Qué es:** Explicar las decisiones en el lenguaje de quien escucha: costo, riesgo, tiempo. - **Por qué:** Una decisión que nadie entendió no tendrá apoyo — o será revertida. - **Ejemplo:** No «necesitamos una cola de mensajes», sino «sin ella, cuando falle el servicio de correo perdemos pedidos — más o menos tantos al mes». - **Trampa:** Hablar en jerga — o aceptarlo todo para evitar una discusión. - **Relaciones:** Se apoya en **Trade-offs**, **ADR** y el **C4 Model**. > **Prueba de la comunicación:** «¿Entenderá una persona nueva, dentro de seis meses, por qué se hizo así?» ## 9. Autoevaluación y hoja de referencia Listas de verificación que el arquitecto repasa antes de cualquier decisión y al final del día. Y todos los conceptos del curso en una sola página. #### Antes de cualquier decisión arquitectónica - **¿Qué problema se está resolviendo realmente?** No la tarea tal como se planteó, sino el problema que hay detrás. - **¿Cuáles son las alternativas?** Al menos tres, incluida «no hacer nada». - **¿Qué pierdo con esta elección?** Nombra al menos dos desventajas. - **¿Qué tan reversible es esta decisión?** Si es reversible — decide rápido. Si no — piensa más. - **¿Cómo se verá esto dentro de dos o tres años?** No idealmente — de forma realista. - **¿Quién, además de mí, necesita entender esta decisión?** Y cómo se la voy a explicar. #### Al mirar cualquier sistema - **¿Qué es lo más frágil de este sistema?** ¿Qué se rompe primero bajo carga? - **¿Qué cambios son fáciles y cuáles dolorosos?** Esa es la medida de la calidad arquitectónica. - **¿Dónde vive la verdad de cada dato importante?** ¿Y dónde están sus copias — cachés, réplicas, proyecciones? - **¿Qué fronteras entre componentes son explícitas y cuáles accidentales?** Las accidentales son deuda técnica. - **¿Qué pasa si se rompe cada dependencia externa?** Una por una. - **Si empezara de nuevo hoy, ¿qué haría distinto?** Esa es la dirección de la evolución. #### Señales de que piensas como arquitecto - Dedicas más tiempo a **discutir y diseñar** que a escribir código. - A menudo preguntas **«por qué»** antes que «cómo». - Nombras los trade-offs **en voz alta**, en lugar de intentar esconderlos. - Escribes **documentos y diagramas** más que la mayoría. - Ves **el sistema entero** y puedes explicar cualquier parte en su contexto. - Piensas en **las personas que trabajarán en esto dentro de un año** — y escribes para que les resulte cómodo. - De vez en cuando **rechazas una tecnología hermosa** porque no hace falta. ### Cómo se conectan los conceptos > Una caja de herramientas: un martillo es inútil sin clavos, y los clavos sin martillo. Los conceptos del curso no viven solos. Una decisión empieza con **Problem Framing**, se sopesa como un **Trade-off**, se revisa su **Reversibility** y se anota en un **ADR**. Un sistema se corta con **Decomposition**, el corte se juzga con **Cohesion & Coupling**, y las partes se encuentran en una **Interface**. Las copias de los datos viven bajo una **Single Source of Truth**, y los reintentos en un mundo async exigen **Idempotency**. _Diagram: Tres cadenas: cómo tomar decisiones, cómo cortar un sistema, cómo vivir con datos y fallos._ ## Hoja de referencia: los 31 conceptos ### Mentalidad - **Problem Framing** (encontrar el problema real): Primero «por qué», luego «cómo». Encuentra el problema detrás del pedido. - **Long-term Thinking** (responsabilidad por las consecuencias): Mira una decisión a tres años; responde por las consecuencias, no por el código. ### Trade-offs y decisiones - **Trade-offs** (compromisos): Toda elección da algo y quita algo. Nombra los ejes en voz alta. - **Simplicity** (KISS): Simple por defecto. Una función sin uso es un impuesto permanente. - **Reversibility** (puerta de un sentido / de dos sentidos): Decide rápido lo reversible, despacio lo irreversible. - **Technical Debt** (deuda técnica): Un atajo ahora, el pago después. Está bien — si queda anotado. ### Diseño del sistema - **Decomposition** (dividir en partes): Partes que se pueden entender cada una por sí sola. - **Cohesion & Coupling** (foco por dentro, pocos vínculos por fuera): Dentro de un módulo — una sola cosa; entre módulos — vínculos mínimos. - **Dependency Rule** (capas, Clean Architecture): Las dependencias apuntan hacia adentro: la lógica de negocio no sabe nada de la base de datos ni del framework. - **Interface over Implementation** (primero el contrato): Primero la frontera, después la implementación. Cambia las implementaciones con libertad. - **Monolith vs Microservices** (una app o muchos servicios): Empieza con un monolito, divide cuando de verdad duela. ### Datos y estado - **Data Model** (entidades, campos, relaciones): Sobrevive al código. Piénsalo primero. - **Single Source of Truth** (SSOT): Cada dato tiene un hogar principal; el resto son copias. - **State** (stateless vs stateful): El estado es complejidad. Mantenlo pequeño y en un solo lugar. - **Transaction** (atomicidad): Varios cambios — todo o nada. - **Cache** (invalidación de caché): Una copia rápida que puede mentir. Lo difícil es cuándo reiniciarla. ### Conexiones y fronteras - **API Contract** (compatibilidad hacia atrás): Una promesa a los clientes. Amplía, nunca quites. - **Sync vs Async** (llamada o carta): Sync acopla en el tiempo; async es más resiliente pero trae retrasos y duplicados. - **Idempotency** (seguro de repetir): Una repetición da el mismo resultado. Imprescindible para pagos y mensajes. - **External Dependencies** (tu propio adapter): Los sistemas ajenos fallarán y cambiarán. Escóndelos detrás de tu capa, planifica la degradación. ### Requisitos no funcionales - **Security** (defense in depth): Protección por capas desde el primer día, mínimo privilegio. - **Performance** (latency, throughput): No «rápido» sino números: carga, latencia, comportamiento en el pico. - **Scalability** (horizontal y modular): Crecer en servidores y módulos, sin reescribir. - **Reliability** (tolerancia a fallos): El fallo de una parte no debe matar todo el sistema. - **Observability** (logs, métricas, trazas): El sistema te cuenta sobre sí mismo. Diséñalo desde el principio. ### Evolución - **Evolvability** (preparación para el cambio): Deja sitio para lo nuevo sin adivinarlo por adelantado. - **Migration** (periodo de transición): No «reescribir desde cero», sino llevar el sistema a través de la transición. - **YAGNI & Deletion** (You Aren't Gonna Need It): No construyas extras; borra lo que ya no hace falta. ### Comunicación - **ADR** (Architecture Decision Record): Qué se eligió, las alternativas, por qué, a qué costo. - **C4 Model** (Context · Container · Component · Code): Diagramas del sistema en cuatro niveles de zoom. - **Stakeholder Communication** (explicar y decir «no»): Habla en costo, riesgo y tiempo; ponte firme cuando haga falta, admite cuando te equivocas. > Un arquitecto no es quien sabe más. Es quien piensa más tiempo antes de empezar. Fin del curso exprés · 9 capítulos · 31 conceptos La práctica viene después. Cada capítulo se despliega en libros: _Designing Data-Intensive Applications_, _Clean Architecture_, _Software Architecture in Practice_, _System Design Interview_. Pero antes de leerlos — hazte las preguntas de este documento. Importan más que las respuestas.