# Software Architect: mentalidad, lenguaje, práctica

Curso completo para un ingeniero senior que quiere pensar y hablar como arquitecto: trade-offs, boundaries, datos, sistemas distribuidos, calidad, comunicación y trabajo AI-native. 52 conceptos, cada uno con su término en inglés, un diagrama y una tarjeta (qué es → ejemplo → coste → relaciones); al final, una chuleta con todos los conceptos.

- **Author:** Fedor Chishchin
- **Level:** advanced
- **Reading time:** ~7 horas de lectura
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/es/learn/software-architect

---

#### Módulos detallados

- [01. Quién es el arquitecto](./software-architect-01-role)
- [02. Trade-offs](./software-architect-02-tradeoffs)
- [03. Deuda técnica](./software-architect-03-technical-debt)
- [04. Cognitive load](./software-architect-04-cognitive-load)
- [05. Descomposición](./software-architect-05-decomposition)
- [06. Capas y dependencias](./software-architect-06-layers)
- [07. APIs y contratos](./software-architect-07-api-contracts)
- [08. Modelo de datos](./software-architect-08-data-model)
- [09. Estado](./software-architect-09-state)
- [10. Sistemas distribuidos](./software-architect-10-distributed-systems)
- [ 11. Monolito y microservicios
  ](./software-architect-11-monolith-microservices)
- [12. Sync y async](./software-architect-12-sync-async)
- [13. Rendimiento](./software-architect-13-performance)
- [14. Escalabilidad](./software-architect-14-scalability)
- [15. Fiabilidad](./software-architect-15-reliability)
- [16. Seguridad](./software-architect-16-security)
- [17. Observability](./software-architect-17-observability)
- [18. Documentación](./software-architect-18-documentation)
- [19. Comunicación](./software-architect-19-communication)
- [20. Liderazgo sin autoridad](./software-architect-20-leadership)
- [21. Negocio y producto](./software-architect-21-business-product)
- [22. Arquitecto AI-native](./software-architect-22-ai-native)
- [23. Antipatrones](./software-architect-23-antipatterns)
- [24. Crecimiento continuo](./software-architect-24-growth)

## 1. Quién es el arquitecto

Un arquitecto se distingue de un ingeniero senior no porque conozca más tecnologías. Se hace responsable de las consecuencias de las decisiones a lo largo del tiempo.

### Mapa del curso — 24 módulos en seis partes

> Un mapa de metro: primero ves todas las líneas de golpe y luego recorres estación por estación.

El curso va de la mentalidad a la práctica. Primero, cómo piensa un arquitecto (**mindset**). Después, cómo se construye un sistema por dentro (**structure**) y qué cambia cuando se reparte por una red (**distribution**). Luego vienen las propiedades de calidad (**quality attributes**), el trabajo con personas (**people**) y hacia dónde va la profesión (**future**).

_Diagram: Los 24 módulos en seis partes: mindset → structure → distribution → quality → people → future._

Cómo leerlo: cada concepto tiene su **término en inglés** (el que buscarás en la documentación y oirás en las entrevistas), una imagen cotidiana, un **diagrama** y una **tarjeta** con los campos «qué es / ejemplo / coste / relaciones». Al final del curso hay una chuleta con todos los conceptos en una sola página.

### Long-term thinking — el arquitecto piensa en años

> Un ingeniero construye un puente por el que mañana pasará un coche. El arquitecto pregunta qué pasa cuando empiecen a usarlo camiones, cuando se levante un barrio nuevo al lado y cuando las reparaciones cuesten más que el propio puente.

Un ingeniero suele resolver el problema **tal como se lo plantean**. El arquitecto primero comprueba si el problema está bien planteado. No es postureo ni ganas de «hablar de cosas profundas». Simplemente, una decisión arquitectónica suele ser más cara de cambiar que una línea de código.

El cambio principal en la cabeza: dejas de preguntar solo «cómo hago X» y empiezas a preguntar **«para qué necesitamos X, qué alternativas hay, qué vamos a perder y cómo se verá esto dentro de tres años»**.

_Diagram: El ingeniero mira la tarea tal como se plantea. El arquitecto estira la misma pregunta a lo largo de los años._

#### Long-term Thinking (pensar en años)

- **Qué es:** Juzgar una decisión no solo por «funciona mañana», sino por cómo se comporta dentro de uno a tres años.
- **Cómo funciona:** Antes de «cómo construyo X»: «para qué X», qué alternativas hay, qué perdemos.
- **Ejemplo:** El puente: ¿aguantará camiones, un barrio nuevo al lado, reparaciones que cuesten más que el puente?
- **Ojo:** No es licencia para construir «para el crecimiento»: es solo una pregunta que hay que hacerse.
- **Relaciones:** **Reversible decisions**, **trade-offs**, **technical debt**.

### Reversible vs irreversible decisions — hacerse cargo de la forma del sistema

> Si un carpintero cuelga mal una estantería, se puede mover. Si el diseñador pone un muro de carga en el sitio equivocado, la casa vive con ese error durante décadas.

El arquitecto no tiene la obligación de tomar personalmente cada decisión técnica. Pero sí de responsabilizarse de las decisiones que dan forma al sistema: fronteras entre servicios, modelo de datos, protocolos de integración, estrategia de escalado, seguridad, observability, ruta de migración.

La distinción útil aquí es entre **decisiones reversibles** y **decisiones irreversibles**. Una decisión reversible se puede cambiar en un día o una semana: una librería de logging, el color de un botón, la estructura interna de un módulo pequeño. Una decisión irreversible, o cara de revertir, cambia la trayectoria del sistema: la base de datos, el modelo de tenancy, un contrato de API, la forma de guardar los eventos, las fronteras entre servicios.

_Diagram: Las decisiones reversibles se toman rápido. Las irreversibles dan forma al sistema: de ellas se responsabiliza el arquitecto._

#### Reversible vs Irreversible (dos tipos de decisiones)

- **Qué es:** Clasificar las decisiones por lo que cuesta deshacerlas: días o semanas frente a meses o años.
- **Cómo funciona:** Las reversibles: se deciden rápido, sin discutir mucho. Las irreversibles: despacio, con alternativas y por escrito.
- **Ejemplo:** Una librería de logging es reversible. El modelo de tenancy o un contrato de API casi no lo son.
- **Ojo:** Una semana de debate sobre un detalle reversible es tan malo como decidir en una hora algo irreversible.
- **Relaciones:** **Data model**, **API contract**, **service boundaries**.

> **La pregunta principal:** Si dentro de un año esta decisión resulta equivocada, ¿cuánta gente y cuántos sistemas la van a pagar?

#### Las preguntas del arquitecto

- ¿Qué problema estamos resolviendo en realidad?
- ¿Qué cambia si la carga crece 10 veces?
- ¿Cuáles de estas decisiones son reversibles y cuáles casi no lo son?
- ¿Quién va a mantener esto dentro de un año?

> El arquitecto no construye «el sistema más correcto»: construye un sistema que sobrevive a la realidad.

## 2. Trade-offs y decisiones

En arquitectura no hay decisiones gratis. Cada elección compra una propiedad a costa de otra.

### Trade-off — una buena práctica sin contexto es un mal consejo

> Un todoterreno gana a un turismo en un camino de barro. El turismo gana al todoterreno en la ciudad. Una bicicleta gana a ambos si hay que ir tres manzanas y no hay dónde aparcar.

Una decisión arquitectónica no se puede evaluar fuera de su contexto. REST, GraphQL, Kafka, PostgreSQL, Kubernetes, microservicios, monolito: todo son herramientas con precio. Un **trade-off** es un intercambio deliberado: latencia frente a throughput, consistencia frente a disponibilidad, time-to-market frente a mantenibilidad, simplicidad frente a flexibilidad.

El arquitecto no dice «Kafka es mejor que RabbitMQ». Dice: «necesitamos orden de eventos por clave, alto throughput, replay y un log duradero; a cambio pagamos la complejidad operativa de Kafka». Así suena el lenguaje profesional.

_Diagram: Cada decisión es un punto en varios ejes a la vez. Si te acercas a un extremo, cedes algo en el otro._

#### Trade-offs (un intercambio deliberado)

- **Qué es:** Una elección que compra una propiedad a costa de otra, hecha en voz alta.
- **Cómo funciona:** Di qué ganas, qué pierdes y por qué ese precio es aceptable ahora.
- **Ejemplo:** «Orden por clave, throughput, replay, un log duradero: se paga con la complejidad operativa de Kafka.»
- **Ojo:** «X es mejor que Y» sin contexto no es un argumento, es gusto.
- **Relaciones:** **CAP / PACELC**, **over-engineering**, **sync vs async**.

### Over-engineering vs under-engineering — la complejidad es un impuesto

> Cada abstracción nueva es como una habitación más en la casa. La habitación puede ser útil, pero hay que limpiarla, calentarla, repararla y explicársela a las visitas.

La complejidad es útil cuando compra una propiedad importante: aislamiento de fallos, despliegue independiente, seguridad, escalado, testabilidad. Pero la complejidad «para el futuro» suele convertirse en un impuesto permanente.

Los términos **over-engineering** y **under-engineering** solo sirven juntos. Over-engineering: la complejidad apareció antes del dolor real. Under-engineering: el sistema ya ha chocado con sus límites y la arquitectura no dejó espacio para crecer. El trabajo del arquitecto no es elegir un extremo, sino sostener el punto medio.

_Diagram: Dos errores en los extremos, la zona correcta en el medio: la complejidad se justifica solo cuando compra una propiedad concreta._

#### Over- / Under-engineering (demasiado vs muy poco)

- **Qué es:** Over: complejidad antes del dolor real. Under: el sistema llegó a sus límites sin camino para crecer.
- **Cómo funciona:** Cada capa o servicio nuevo tiene que nombrar la propiedad que compra.
- **Ejemplo:** Microservicios y Kafka desde el lanzamiento para 200 usuarios: over. Una tabla sin índices cuando la carga crece 10 veces: under.
- **Ojo:** La complejidad «para el futuro» no desaparece: la pagas cada día.
- **Relaciones:** **Trade-off**, **technical debt**, **cognitive load**.

> **La pregunta para cada decisión:** ¿Qué ganamos, qué perdemos y por qué ese precio es aceptable ahora?

#### Para seguir leyendo

- Architecture: The Hard Parts — Ford, Richards, Sadalage, Dehghani
- Software Architecture in Practice — Bass, Clements, Kazman
- Martin Fowler: Is Design Dead?

## 3. Deuda técnica

La deuda técnica no siempre es mala. Lo malo es la deuda contraída por accidente, sin anotar y sin intención de pagarla.

### Technical debt — un préstamo, no basura

> Un préstamo para comprar equipo puede acelerar un negocio. Un préstamo para una fiesta solo deja resaca e intereses.

La **deuda técnica** es una decisión que nos acelera ahora pero crea un coste futuro de cambio. A veces es lo correcto: hay que probar el mercado, cumplir un plazo, retener a un cliente. El problema empieza cuando el equipo etiqueta todo como deuda: código malo, falta de tests, dependencias caóticas, librerías anticuadas.

Un modelo útil es el **Technical Debt Quadrant de Martin Fowler**: deliberada / inadvertida y prudente / imprudente. Deuda deliberada y prudente: «de momento no hacemos multi-región porque tenemos 200 usuarios y un solo mercado». Deuda inadvertida e imprudente: «no sabíamos que necesitábamos transacciones».

_Diagram: El cuadrante de Fowler: la deuda se puede contraer de forma deliberada y prudente (arriba a la derecha). Las celdas de la izquierda son las peligrosas._

#### Technical Debt (pedir prestado contra el cambio futuro)

- **Qué es:** Una decisión que nos acelera ahora pero crea un coste futuro de cambio.
- **Cómo funciona:** Contráela de forma deliberada, anota qué y por qué, y fija un disparador para revisarla.
- **Ejemplo:** «Sin multi-región por ahora: 200 usuarios, un mercado»: deliberada y prudente.
- **Ojo:** Si todo se llama deuda (código malo, sin tests, librerías viejas), la palabra deja de significar algo.
- **Relaciones:** **Debt interest**, **ADR** (registrar la decisión), **trade-off**.

### Debt interest — la deuda cobra intereses

> Si la carretera está rota, cada viaje dura cinco minutos más. Un mes después ya no es un bache: es un impuesto sobre toda la ciudad.

Los intereses de la deuda técnica son la ralentización de cada cambio siguiente. Cuanto más a menudo toca el equipo una zona, más cara es la deuda. Por eso la deuda en el dominio caliente es más peligrosa que la de un panel de administración que casi nadie usa.

El arquitecto negocia una estrategia de pago: qué cuenta exactamente como deuda, qué riesgo crea, cuándo revisamos la decisión, qué señal dice «es hora de pagar». Sin eso, la «deuda técnica» se vuelve un argumento emocional, no un instrumento gestionado.

_Diagram: La misma deuda: en el dominio caliente los intereses se cobran en cada cambio; en el panel de administración, casi nunca._

#### Debt Interest (el coste corriente de la deuda)

- **Qué es:** La ralentización de cada cambio siguiente en el código que arrastra deuda.
- **Cómo funciona:** Intereses ≈ ralentización × con qué frecuencia el equipo toca esa zona.
- **Ejemplo:** La deuda en pagos, que cambia cada semana, cuesta más que la de un panel de administración que se abre una vez por trimestre.
- **Ojo:** Sin una estrategia de pago, la «deuda técnica» se convierte en un argumento emocional.
- **Relaciones:** **Technical debt**, **cognitive load**.

> **La pregunta clave:** ¿Esta deuda nos está comprando tiempo o solo disimula una mala decisión?

#### Preguntas para una revisión de deuda

- ¿Dónde está escrito por qué aceptamos este compromiso?
- ¿Qué intereses pagamos cada sprint?
- ¿Qué tendría que pasar para que esta deuda se convierta en un bloqueo?
- ¿Hay un plan de pago, o al menos un disparador para revisarla?

## 4. Cognitive load

Un sistema que nadie puede tener en la cabeza se romperá incluso con ingenieros fuertes.

### Cognitive load — la arquitectura tiene que caber en una cabeza humana

> Un mapa de metro es útil no porque muestre cada tornillo del túnel. Muestra líneas, transbordos y dirección de viaje. Eso basta para decidir.

La **cognitive load** es el esfuerzo mental que un sistema exige a un ingeniero. Existe la **intrinsic load**: la complejidad del propio dominio. Y la **extraneous load**: complejidad extra por mala arquitectura, vínculos poco obvios, excepciones accidentales y magia. El arquitecto no puede quitar la complejidad del negocio, pero está obligado a reducir la complejidad accidental.

Un buen módulo se entiende por sí solo. Un buen bounded context tiene su propio lenguaje y sus propios invariantes. Un buen equipo es dueño de un área que cabe en su cabeza.

_Diagram: La complejidad del dominio (intrinsic) siempre está ahí. La arquitectura decide cuánta complejidad extra (extraneous) se apila encima, y si todo cabe en una cabeza._

#### Cognitive Load (esfuerzo mental)

- **Qué es:** Cuánto contexto tiene que sostener un ingeniero en la cabeza para cambiar algo con seguridad.
- **Cómo funciona:** La intrinsic es la complejidad propia del dominio: se queda. La extraneous es accidental: recórtala.
- **Ejemplo:** Un módulo que se entiende por sí solo frente a uno donde nada tiene sentido sin la «magia» y las excepciones.
- **Ojo:** Los ingenieros fuertes no pueden salvar un sistema que no cabe en una cabeza.
- **Relaciones:** **Bounded context**, **Conway's Law**, **decomposition**.

### Conway's Law — la estructura de los equipos se convierte en la estructura del sistema

> Si tres departamentos no hablan entre sí, su producto casi siempre parece tres productos pegados en un solo menú.

La **Conway's Law** dice: una organización diseña sistemas que reflejan la estructura de comunicación dentro de la organización. Si las fronteras arquitectónicas no coinciden con las de los equipos, el equipo seguirá invadiendo territorio ajeno.

**Team Topologies** introduce etiquetas útiles: stream-aligned team, platform team, enabling team, complicated-subsystem team. No es moda de recursos humanos: es una herramienta arquitectónica. A veces, la descomposición correcta del sistema empieza por la descomposición correcta de la responsabilidad.

_Diagram: Conway's Law: el sistema refleja cómo se comunican los equipos. Team Topologies da cuatro tipos de equipo para cortarlo a propósito._

#### Conway's Law (más Team Topologies)

- **Qué es:** Un sistema refleja la estructura de comunicación de la organización que lo construye.
- **Cómo funciona:** Alinea las fronteras de los equipos con las del sistema: cada equipo es dueño de su área.
- **Ejemplo:** Tres departamentos que no hablan entre sí entregan «tres productos en un menú».
- **Ojo:** Si las fronteras no coinciden, los equipos se siguen pisando el terreno.
- **Relaciones:** **Team Topologies** (stream-aligned, platform, enabling, complicated-subsystem), **bounded context**.

> **La pregunta clave:** ¿Cuánto contexto necesita cargar un ingeniero para cambiar este componente con seguridad?

## 5. Descomposición del sistema

Un sistema grande solo se vuelve manejable cuando puedes cortarlo por las fronteras correctas.

### Cohesion & coupling — cortar por capas, por dominios o por flujo de datos

> Un carnicero no corta la res al azar: corta por las articulaciones. Una buena descomposición también busca puntos de ruptura naturales.

Descomponer no es «ordenar en carpetas». Es elegir dónde termina la responsabilidad. **Alta cohesión** significa que todo dentro de un componente trata de una sola cosa. **Bajo acoplamiento** significa que el componente sabe poco de los demás.

Un corte horizontal da **capas**: UI, aplicación, dominio, infraestructura. Un corte vertical da features o **bounded contexts**: facturación, identidad, catálogo, comentarios. Los sistemas reales necesitan ambos, pero confundir uno con otro es peligroso.

_Diagram: Un corte horizontal da capas; uno vertical, features y contextos. Un sistema real es una cuadrícula de ambos._

#### Cohesion & Coupling (apretado por dentro, suelto entre medias)

- **Qué es:** Todo dentro de un componente trata de una sola cosa (cohesión); sabe poco de los demás (acoplamiento).
- **Cómo funciona:** Corta en horizontal (capas) y en vertical (features / contextos), y no los confundas.
- **Ejemplo:** Un módulo `billing` con sus propias capas UI → application → domain → infra.
- **Ojo:** «Ordenar en carpetas» todavía no es descomponer.
- **Relaciones:** **Bounded context**, **layers**, **modular monolith**.

### Bounded context — una mala frontera se delata con el cambio

> Si cambiar el grifo de la cocina obliga a desmontar el dormitorio, el problema no es el grifo.

Una señal de mala descomposición: un cambio pequeño se propaga por cinco módulos. Otra señal: un módulo cambia por razones distintas: hoy por el producto, mañana por la base de datos, pasado mañana por una integración.

El término de DDD **bounded context** es útil justo aquí. Es una frontera dentro de la cual las palabras tienen un solo significado. «Customer» en facturación y «Customer» en soporte pueden ser modelos distintos. Forzarlos en uno solo suele crear un modelo «universal» frágil.

_Diagram: Una palabra, dos modelos: Customer en facturación y Customer en soporte significan cosas distintas, y eso está bien._

#### Bounded Context (una frontera de significado de DDD)

- **Problema:** Un cambio pequeño se propaga por cinco módulos; un módulo cambia por razones distintas.
- **Idea:** Una frontera dentro de la cual cada palabra tiene un significado y un modelo.
- **Ejemplo:** «Customer» en facturación y «Customer» en soporte son modelos distintos.
- **Coste:** Hay que mapear los modelos en las fronteras; traducción entre contextos.
- **Cuándo usarlo:** Cuando un mismo concepto significa cosas distintas para partes distintas del negocio.
- **Relaciones:** **Cohesion / coupling**, **Conway's Law**, **microservices**.

> **Test de descomposición:** ¿Puedo explicar este componente sin contarte la mitad del sistema?

## 6. Capas y dirección de las dependencias

La lógica de negocio debe depender de las reglas de negocio, no del framework, la base de datos ni HTTP.

### Dependency Rule y DIP — las dependencias fluyen hacia el centro

> La cimentación no debería depender del color de las cortinas. Si depende, la casa se diseñó al revés.

**Clean Architecture**, **Hexagonal Architecture** y **Onion Architecture** dicen lo mismo: la lógica importante va en el centro y los detalles, fuera. HTTP, SQLAlchemy, Next.js, Kafka, Redis, Stripe: son detalles. Importan, pero no deben definir las reglas de negocio.

El **Dependency Inversion Principle** dice: la lógica de alto nivel depende de abstracciones y las implementaciones se enchufan desde fuera. En código se ve como puertos y adaptadores: el servicio recibe un `PaymentGatewayProtocol`, no construye un `StripeClient` por dentro.

_Diagram: El dominio, en el centro, depende solo de un puerto. StripeClient, HTTP y la base de datos son detalles de fuera; todas las flechas apuntan hacia dentro._

#### Dependency Inversion (DIP, la regla de dependencia)

- **Problema:** Las reglas de negocio se han incrustado en el framework y la base de datos: no se pueden probar ni reemplazar.
- **Idea:** La lógica de alto nivel depende de abstracciones; las implementaciones se enchufan desde fuera.
- **Ejemplo:** El servicio recibe un `PaymentGatewayProtocol` en lugar de construir un `StripeClient`.
- **Coste:** Más interfaces y más archivos.
- **Cuándo usarlo:** Hay reglas de negocio reales que deben sobrevivir a los cambios de tecnología.
- **Relaciones:** **Clean / Hexagonal / Onion Architecture**, **ports and adapters**.

### Abstraction — existe para absorber el cambio, no para quedar bonito

> Un adaptador va donde los enchufes realmente son distintos. Si pones un adaptador en cada toma solo porque te gustan los adaptadores, la casa se vuelve menos segura.

No toda clase necesita una interfaz. Pero todo lo que toca el mundo exterior, el tiempo, la aleatoriedad, la red, el sistema de archivos o la base de datos debe poder reemplazarse en los tests. Si no, no estás probando lógica de negocio: estás levantando un pequeño sistema de producción dentro de un test unitario.

El precio de una capa son más archivos y más palabras. La recompensa es testabilidad, infraestructura intercambiable y fronteras limpias. Si no hay recompensa, la capa es lastre.

_Diagram: Esconde el mundo exterior (tiempo, aleatoriedad, red, archivos, base de datos) detrás de un puerto y pon un fake en los tests. La lógica pura no necesita interfaz._

#### Abstraction (interfaces donde empuja el cambio)

- **Qué es:** Una interfaz va donde la implementación realmente cambia o estorba a los tests.
- **Cómo funciona:** Tiempo, aleatoriedad, red, archivos, base de datos → detrás de un puerto; un fake en los tests, el adaptador real en producción.
- **Ejemplo:** Una regla de negocio se prueba sin base de datos, sin HTTP y sin tiempo real: en milisegundos.
- **Ojo:** Una capa sin recompensa son archivos y palabras de más, no arquitectura.
- **Relaciones:** **DIP**, **testability**, **over-engineering**.

> **La pregunta clave:** ¿Puedo probar esta regla de negocio sin base de datos, sin HTTP y sin tiempo real?

## 7. APIs y contratos

Una API es una promesa. Romper una promesa es fácil; reconstruir la confianza de los clientes es difícil.

### API contract — el contrato importa más que el transporte

> Al control de pasaportes no le importa la marca de la puerta. Importa qué documentos se aceptan, qué reglas se aplican y qué pasa cuando algo falla.

**REST**, **GraphQL**, **gRPC** y **WebSocket** son formas distintas de hablar. REST encaja con APIs orientadas a recursos y con caché sencilla. GraphQL ayuda cuando clientes distintos necesitan formas distintas de lectura. gRPC va bien para comunicación tipada entre servicios. WebSocket sirve para eventos bidireccionales en tiempo real.

La elección del transporte es secundaria. Lo que importa es el **API contract**: esquema, errores, idempotencia, versionado, **backward compatibility**, **deprecation policy**.

_Diagram: El transporte de la izquierda puede cambiar. El contrato de la derecha es una promesa a los clientes, y es caro romperlo._

#### API Contract (la promesa a los clientes)

- **Qué es:** Una promesa: esquema, errores, idempotencia, versiones, compatibilidad, reglas para retirar lo viejo.
- **Cómo funciona:** Primero se acuerda el contrato; después se elige el transporte adecuado.
- **Ejemplo:** REST para recursos y caché; GraphQL para lecturas variadas; gRPC para comunicación tipada entre servicios; WebSocket para tiempo real.
- **Ojo:** Romper una promesa es fácil; reconstruir la confianza de los clientes es difícil.
- **Relaciones:** **Idempotency**, **versioning**, **reversible vs irreversible**.

### Idempotency — te salva del mundo real

> Si pulsas diez veces el botón del ascensor, el ascensor no debería llegar y marcharse diez veces. Debería entender que la intención es una sola.

La **idempotencia** significa que repetir una operación produce el mismo efecto final. En sistemas en red los reintentos son inevitables: timeouts, retries, webhooks duplicados, reinicios de workers. Si crear un pago, un pedido o un mensaje no es idempotente, tarde o temprano el sistema hará algo de más.

El arquitecto diseña la idempotencia a nivel de contrato: **idempotency key**, unique constraints, reintentos seguros, estados claros.

_Diagram: El cliente envió la petición tres veces con una sola clave: el servidor reconoció la clave y creó un solo pago._

#### Idempotency (operaciones seguras de repetir)

- **Qué es:** Repetir una operación da el mismo efecto final que la primera llamada.
- **Cómo funciona:** Una idempotency key en la petición + una unique constraint en la base de datos + estados claros.
- **Ejemplo:** Un pago da timeout → el cliente repite `POST /payments` con la misma clave → se cobra una vez.
- **Ojo:** Sin ella, las repeticiones (retries, webhooks duplicados, reinicios de workers) acaban haciendo algo de más.
- **Relaciones:** **At-least-once delivery**, **API contract**, **retries**.

> **La pregunta clave:** ¿Qué pasa si el cliente repite esta petición tres veces?

## 8. El modelo de datos

El código se reescribe. Los datos migran durante años. Por eso el modelo de datos es una de las decisiones arquitectónicas más caras.

### Data model — los datos viven más que las aplicaciones

> Una fachada se repinta en una semana. Una cimentación mal vertida te lo recuerda durante toda la vida del edificio.

El lenguaje, el framework y la UI pueden cambiar varias veces. Pero las tablas, los eventos, las claves, las relaciones y los registros históricos se quedan. Un error en el modelo de datos suele convertirse en un error en todas las versiones futuras del producto.

La **normalización** reduce la duplicación y el riesgo de divergencia. La **desnormalización** acelera las lecturas y simplifica el read model. Los sistemas **OLTP** están optimizados para transacciones, los **OLAP** para analítica. No se puede diseñar un único modelo como si fuera a servir perfectamente a ambas clases de trabajo.

_Diagram: La app se reescribió tres veces; los datos se quedaron. Abajo: dos tipos de trabajo distintos: transacciones (OLTP) y analítica (OLAP)._

#### Data Model (más OLTP / OLAP)

- **Qué es:** Tablas, eventos, claves, relaciones e historial: lo que sobrevive a cada reescritura del código.
- **Cómo funciona:** Normalización: menos duplicados y menos divergencia; desnormalización: lecturas más rápidas.
- **Ejemplo:** Una base de datos OLTP para pedidos y un almacén OLAP aparte para informes.
- **Ojo:** Un error en el modelo de datos se convierte en un error en todas las versiones futuras del producto.
- **Relaciones:** **Irreversible decisions**, **event sourcing**, **CQRS**.

### Event sourcing y CQRS — una herramienta potente, no una religión

> Un extracto bancario no guarda solo el saldo actual: guarda el historial de operaciones. Eso es lo que permite explicar de dónde sale el saldo.

**Event sourcing** guarda los cambios como una secuencia de eventos y reconstruye el estado actual a partir de ellos. Es útil cuando importan el historial, la auditoría, la recuperación de estado y el replay. El precio es alto: evolución del esquema de eventos, complejidad de las consultas, eventual consistency, herramientas exigentes.

**CQRS** separa el modelo de escritura del modelo de lectura. Puede simplificar mucho los sistemas de lectura complejos, pero añade sincronización y retraso. Introducir CQRS solo porque «suena a arquitectura» es una forma cara de convertir un problema en dos.

_Diagram: Un comando escribe eventos en el log; una proyección construye con ellos un read model, y las consultas leen de ahí._

#### Event Sourcing (el estado como log de eventos)

- **Problema:** El estado actual no explica cómo llegamos hasta aquí.
- **Idea:** Guardar los cambios como un log de eventos; estado = reproducirlos.
- **Ejemplo:** Un extracto bancario: el saldo es la suma de las operaciones.
- **Coste:** Evolución del esquema de eventos, consultas más difíciles, eventual consistency, herramientas exigentes.
- **Cuándo usarlo:** Importan el historial, la auditoría, la recuperación de estado y el replay.
- **Relaciones:** Suele ir junto con **CQRS**.

#### CQRS (Command Query Responsibility Segregation)

- **Problema:** Un solo modelo sirve mal tanto a las escrituras como a las lecturas complejas.
- **Idea:** Separar el modelo de escritura del modelo de lectura.
- **Ejemplo:** Los pedidos se escriben en un modelo normalizado; la pantalla de informes lee una vista ya preparada.
- **Coste:** Sincronización y retraso entre los modelos.
- **Cuándo usarlo:** Cuando las lecturas son realmente complejas, no porque «suene a arquitectura».
- **Relaciones:** **Event sourcing**, **denormalization**, **eventual consistency**.

> **La pregunta clave:** ¿Qué hechos de este sistema tienen que sobrevivir a tres reescrituras de la aplicación?

## 9. Estado y fuente de la verdad

El estado es complejidad que vive en algún sitio. Cuantas más copias de la verdad, más formas de equivocarse.

### Single source of truth — no significa una sola base de datos

> Una empresa puede tener muchos informes, pero tiene que haber un único registro oficial de nóminas. Si no, el día de pago se convierte en teatro.

**Single source of truth** significa que, para cada hecho importante, sabes dónde vive la versión autorizada. Una caché, un índice de búsqueda, una read replica, una vista materializada: son copias derivadas. Pueden ser útiles, pero no deben hacerse pasar por la verdad primaria.

Los componentes **stateful** guardan estado y exigen cuidado: transacciones, bloqueos, recuperación, backup. Los componentes **stateless** son más fáciles de escalar y reemplazar, pero siguen dependiendo de un estado que vive en otro sitio.

_Diagram: A la izquierda, apps stateless; en el medio, una base de datos autorizada; a la derecha, copias derivadas, que no son la verdad._

#### Single Source of Truth (un dueño por hecho)

- **Qué es:** Para cada hecho importante, está claro dónde vive su versión autorizada.
- **Cómo funciona:** Un registro primario; la caché, el índice, la réplica y la vista son copias derivadas.
- **Ejemplo:** Muchos informes, pero un único registro oficial de nóminas.
- **Ojo:** No significa «una base de datos para todo»: significa «un dueño por hecho».
- **Relaciones:** **Stateful / stateless**, **cache**, **CQRS**.

### Cache y locking — una segunda verdad que a veces miente

> El horario pegado en la nevera es cómodo, hasta que alguien mueve la reunión en el calendario del móvil.

Una **cache** compra velocidad a costa de frescura. La pregunta más difícil sobre la caché no es «cómo meter cosas», sino «cuándo invalidar». **TTL**, **explicit invalidation**, **write-through**, **write-behind**, **cache-aside**: son compromisos distintos entre complejidad, frescura y carga.

_Diagram: Cache-aside: leer la caché; si falla, ir a la base de datos y guardar la respuesta en la caché. A la derecha: estrategias de invalidación._

Una **race condition** aparece cuando dos operaciones compiten por un estado. El **optimistic locking** dice: «los conflictos son raros, comprobaremos la versión al escribir». El **pessimistic locking** dice: «los conflictos son peligrosos, bloquearemos de antemano». Ambos son correctos en condiciones distintas.

_Diagram: A la izquierda, el optimistic locking detecta el conflicto por versión al escribir. A la derecha, el pessimistic locking obliga al segundo escritor a esperar._

#### Cache Invalidation (la caché y cómo mantenerla fresca)

- **Qué es:** Una copia de los datos más cerca del lector: velocidad a cambio de frescura.
- **Cómo funciona:** TTL, invalidación explícita, write-through, write-behind, cache-aside: compromisos distintos.
- **Ejemplo:** El horario de la nevera frente al calendario del móvil.
- **Ojo:** La pregunta principal no es «cómo meterlo», sino «cuándo tirarlo».
- **Relaciones:** **Single source of truth**, **eventual consistency**.

#### Optimistic vs Pessimistic Locking (dos formas de manejar las carreras)

- **Qué es:** Dos formas de impedir que dos operaciones corrompan un estado compartido (una race condition).
- **Cómo funciona:** Optimistic: comprobar la versión al escribir. Pessimistic: bloquear de antemano.
- **Ejemplo:** Dos gerentes editan el mismo registro: el segundo recibe un conflicto y vuelve a leer los datos.
- **Ojo:** El optimistic sufre con conflictos frecuentes; el pessimistic sufre con mucha contención de bloqueos.
- **Relaciones:** **Transactions**, **stateful components**.

> **La pregunta clave:** ¿Dónde vive la verdad de cada hecho y qué pasa si las copias divergen?

## 10. Sistemas distribuidos

La distribución resuelve problemas de escala, pero crea problemas de tiempo, orden y confianza en la red.

### CAP y PACELC — la red es una fuente de incertidumbre

> Un monolito es una conversación en una sola habitación. Un sistema distribuido es una correspondencia entre personas en husos horarios distintos: las cartas a veces se pierden, llegan dos veces o se retrasan.

En un sistema distribuido no puedes simplemente «llamar a una función». Entre servicios hay red, timeouts, retries, **partial failure**, relojes distintos, versiones de código distintas. Lo que en el monolito era una transacción local se convierte en un protocolo de coordinación.

El **teorema CAP** se suele resumir mal. La versión útil en la práctica: durante una **network partition**, eliges entre consistencia y disponibilidad. **PACELC** añade: incluso sin partición, sigues eligiendo entre latencia y consistencia.

_Diagram: El enlace entre nodos se corta: elige consistencia o disponibilidad. Sin corte, sigues eligiendo: latencia o consistencia._

#### CAP / PACELC (las elecciones de los sistemas distribuidos)

- **Qué es:** Durante una partición: C o A (CAP). Sin ella: L o C (PACELC).
- **Cómo funciona:** Cada almacén y cada escenario declara explícitamente a qué renuncia.
- **Ejemplo:** Un nodo aislado de su par: negarse a responder (C) o responder, quizá con datos viejos (A).
- **Ojo:** «Elegimos CA» no existe en una red: las particiones ocurren; la única pregunta es qué haces entonces.
- **Relaciones:** **Consistency models**, **trade-off**, **partial failure**.

### Consistency models y Saga — la consistencia viene en sabores

> Dos personas mirando el mismo Google Doc ven lo mismo casi al instante. Dos personas mirando una transferencia bancaria no pueden conformarse con «casi».

La **strong consistency** te da la verdad fresca, pero cuesta latencia y disponibilidad. La **eventual consistency** tolera una divergencia temporal, pero a menudo escala mejor. La **causal consistency** conserva la causa y el efecto: si el evento B depende de A, B no debe hacerse visible antes que A.

_Diagram: La escala de consistencia: de eventual (escala, tolera divergencia) a strong (fresca, pero más cara)._

El **saga pattern** divide una transacción de negocio larga en pasos con **compensating actions**. El **two-phase commit** da atomicidad entre recursos, pero es caro y frágil en sistemas distribuidos reales. El arquitecto elige no el modelo «más estricto», sino el suficiente para el riesgo.

_Diagram: Saga: el paso 3 falló; las compensating actions deshacen los pasos 2 y 1 ya completados, en orden inverso._

#### Consistency Models (strong · causal · eventual)

- **Qué es:** Con qué rapidez, y en qué orden, todos ven la misma verdad.
- **Cómo funciona:** Strong: siempre fresca. Causal: conserva el orden causa-efecto. Eventual: se pone al día después.
- **Ejemplo:** Un documento compartido: «casi al instante» vale. Una transferencia bancaria: no.
- **Ojo:** Strong paga en latencia y disponibilidad; eventual paga en divergencia temporal.
- **Relaciones:** **CAP / PACELC**, **cache**, **CQRS**.

#### Saga (una transacción larga con compensaciones)

- **Problema:** Una operación de negocio abarca varios servicios; no hay una transacción compartida.
- **Idea:** Una cadena de pasos; si uno falla, las compensating actions deshacen lo hecho.
- **Ejemplo:** Reservar stock → cobrar → falla el envío → reembolsar → liberar la reserva.
- **Coste:** Cada paso necesita una compensación; los estados intermedios son visibles.
- **Cuándo usarlo:** En lugar del **two-phase commit**, que es costoso y frágil a través de una red.
- **Relaciones:** **Eventual consistency**, **idempotency**, **microservices**.

> **La pregunta clave:** ¿Qué tiene que ser consistente de inmediato y qué se permite que se ponga al día después?

## 11. Monolito y microservicios

Los microservicios no arreglan un mal diseño. Convierten problemas locales en problemas distribuidos.

### Modular monolith — un comienzo a menudo infravalorado

> Un almacén bien organizado es más rápido que diez pequeños si el mismo repartidor tiene que ir de uno a otro de todos modos.

Un monolito no es un insulto. Un mal monolito es una maraña de dependencias sucias. Un buen **modular monolith** tiene fronteras internas estrictas, dominios separados, interfaces explícitas y una sola **deployment unit**. Para un equipo pequeño suele ser el mejor punto de partida.

Los **microservicios** ayudan cuando necesitas releases independientes, equipos autónomos, perfiles de escalado distintos, aislamiento de fallos o stacks tecnológicos distintos. El precio: llamadas de red, observability, transacciones distribuidas, sobrecarga de DevOps, versionado, seguridad entre servicios.

_Diagram: A la izquierda, una unidad de despliegue con muros fuertes por dentro. A la derecha, servicios separados con sus propias bases de datos y la factura de la red._

#### Modular Monolith (un despliegue, muros fuertes)

- **Problema:** El monolito se convierte en una maraña de dependencias sucias.
- **Idea:** Fronteras internas estrictas e interfaces explícitas, pero una sola unidad de despliegue.
- **Ejemplo:** Módulos de facturación, identidad y catálogo en una sola app, que hablan mediante APIs de módulo.
- **Coste:** Requiere disciplina en las fronteras; escala y se despliega como un todo.
- **Cuándo usarlo:** Un equipo pequeño, un producto temprano. **Microservices**: cuando necesitas releases independientes, equipos autónomos, perfiles de carga distintos, aislamiento de fallos.
- **Relaciones:** **Bounded context**, **microservices**, **Strangler Fig**.

### Distributed monolith y Strangler Fig — lo peor de ambos mundos, y la salida

> Es como vivir en apartamentos separados pero ir al de al lado a por cada cuchara.

Un **distributed monolith** parece microservicios, pero los servicios no son autónomos: esquema de base de datos compartido, cadenas de llamadas síncronas, releases que solo salen juntos, cambios que obligan a tocar a todos. El equipo paga el coste de la distribución sin obtener la independencia.

_Diagram: Distributed monolith: servicios atados por una cadena síncrona y un esquema compartido; sin independencia._

El **Strangler Fig pattern** permite migrar con cuidado: envolver el sistema viejo, extraer capacidades poco a poco, cortar por fronteras de negocio reales, no por tablas.

_Diagram: Strangler Fig: una fachada delante del sistema viejo traslada las capacidades a servicios nuevos una a una, hasta que el viejo desaparece._

#### Distributed Monolith (microservicios solo de nombre)

- **Señales:** Esquema de base de datos compartido, cadenas de llamadas síncronas, releases solo juntos, cada cambio toca a todos.
- **Por qué duele:** Pagas por la distribución y no obtienes independencia.
- **Ejemplo:** Apartamentos separados, pero al de al lado por cada cuchara.
- **Salida:** Datos propios por servicio, enlaces asíncronos, fronteras por significado de negocio, o volver a un modular monolith.
- **Relaciones:** **Modular monolith**, **bounded context**, **sync vs async**.

#### Strangler Fig (reemplazo gradual)

- **Problema:** El sistema viejo no se puede reescribir de una vez.
- **Idea:** Envolverlo en una fachada y mover poco a poco las capacidades a servicios nuevos.
- **Ejemplo:** Extraer primero facturación, luego catálogo: la fachada enruta las peticiones.
- **Coste:** Dos sistemas conviven durante mucho tiempo.
- **Cuándo usarlo:** Migrar un sistema vivo sin una «gran reescritura».
- **Relaciones:** Corta por **bounded contexts**, no por tablas.

> **La pregunta clave:** ¿Qué dolor estamos tratando con microservicios: carga, equipos, releases, tolerancia a fallos, o solo aburrimiento?

## 12. Sync y async

Sync acopla los sistemas en el tiempo. Async rompe ese acoplamiento, pero trae retrasos, duplicados y complejidad de orden.

### Queue y pub/sub — una cola no es solo «luego»

> Una llamada de teléfono exige que ambos lados estén libres ahora. Una carta se puede leer luego, pero puede perderse, retrasarse o exigir respuesta.

Una llamada **síncrona (sync)** es fácil de razonar: envías, recibes respuesta. Pero si el receptor es lento o no está disponible, sufre el emisor. **Async** mediante una **queue** o **pub/sub** permite aguantar fallos y picos de carga, pero exige otro modelo mental.

Una cola suele repartir el trabajo entre consumidores. Pub/sub difunde un evento a muchos suscriptores. Kafka, RabbitMQ, SQS, Redis Streams: herramientas distintas con modelos distintos de orden, durabilidad, replay y operación.

_Diagram: Sync: el emisor espera. Queue: cada mensaje va a un worker. Pub/sub: cada evento llega a todos los suscriptores._

#### Queue vs Pub/Sub (reparto de trabajo vs difusión)

- **Problema:** Una llamada sync acopla los sistemas en el tiempo: el receptor cae, sufre el emisor.
- **Idea:** Una cola reparte el trabajo entre consumidores; pub/sub envía un evento a cada suscriptor.
- **Ejemplo:** Kafka, RabbitMQ, SQS, Redis Streams: orden, durabilidad y replay distintos.
- **Coste:** Retrasos, duplicados, complejidad de orden.
- **Cuándo usarlo:** El emisor no necesita el resultado ahora mismo; hay que aguantar fallos y picos.
- **Relaciones:** **At-least-once delivery**, **backpressure**, **idempotency**.

### At-least-once delivery — exactly-once casi siempre es marketing

> Si una carta se envía dos veces, una contabilidad decente no debería pagar el sueldo dos veces.

En la práctica diseñas para **at-least-once delivery** más un **idempotent consumer**. Un mensaje puede llegar dos veces; el handler tiene que sobrevivir a eso. Una **dead letter queue** es para los mensajes que no se pudieron procesar tras un número razonable de intentos.

**Backpressure** es la señal «el receptor no da abasto». Sin ella, el sistema acepta todo con elegancia y luego muere por dentro.

_Diagram: Un mensaje puede llegar dos veces: el consumidor descarta los duplicados por id. Tras N fallos va a la DLQ. El backpressure pide al emisor que baje el ritmo._

#### At-least-once Delivery (más DLQ y backpressure)

- **Qué es:** Se garantiza que un mensaje llega, pero quizá más de una vez.
- **Cómo funciona:** Un idempotent consumer descarta duplicados; una dead letter queue recoge mensajes tras N fallos; el backpressure dice «no doy abasto».
- **Ejemplo:** Un mensaje duplicado de «pagar el sueldo» no lo paga dos veces.
- **Ojo:** «Exactly-once» casi siempre es marketing; sin backpressure el sistema acepta todo y muere por dentro.
- **Relaciones:** **Idempotency**, **queue / pub/sub**, **reliability**.

> **La pregunta clave:** ¿El emisor necesita saber el resultado ahora mismo, o basta con meter el trabajo en el pipeline de forma fiable?

## 13. Rendimiento y medición

«Hazlo rápido» no es un requisito. Un requisito suena a latencia, throughput, percentiles y perfil de carga.

### Tail Latency — el tiempo de respuesta medio casi siempre miente

> Si nueve personas recibieron su comida en un minuto y la décima esperó una hora, el promedio parece tolerable. La décima no opina lo mismo.

Este es el concepto de **tail latency**. Primero, tres palabras. **Latency** es el retraso de una sola operación. **Throughput** es cuántas operaciones maneja el sistema por unidad de tiempo. Los **percentiles** muestran la distribución: **p50** es la mediana, **p95** significa que el 95 % de las peticiones son más rápidas que ese valor, **p99** es la cola.

El usuario no siente el promedio: siente la cola. La tail latency importa sobre todo en sistemas donde una pantalla depende de varias llamadas al backend: la probabilidad de una respuesta lenta se acumula.

_Diagram: La mayoría de las peticiones son rápidas, pero la cola (p95, p99) es larga. El promedio la esconde; el usuario la siente._

#### Tail Latency (p95 / p99)

- **Problema:** El tiempo de respuesta medio parece bien mientras algunos usuarios esperan muchísimo.
- **Idea:** Mira los percentiles: p50 es la mediana, p95 y p99 son la cola.
- **Ejemplo:** Una pantalla se construye con cinco llamadas al backend: si una cualquiera cae en la cola, toda la pantalla va lenta.
- **Coste:** Recoges una distribución, no un número; necesitas histogramas en tus métricas.
- **Cuándo usarlo:** Cada vez que conviertes «rápido» en un requisito o montas un SLO.
- **Relaciones:** La base de los **SLOs**; crece durante una **retry storm**; se ve a través de la **observability**.

### Profiling — haz profile antes de optimizar

> Arreglar el rendimiento sin un profile es como tratar a un paciente a partir de una foto de sus zapatos.

Esta es la práctica del **profiling**: primero mide, luego optimiza. Consultas N+1, round trips de más, un mal índice, serialización, contención de bloqueos, pausas de GC, caché fría: todo parece «lento», pero se cura de formas distintas.

La **Ley de Amdahl** te recuerda: la aceleración está limitada por la parte del sistema que realmente optimizas. La **Ley de Little** ayuda a pensar en colas: más latencia con el mismo throughput significa más trabajo en curso dentro del sistema.

_Diagram: El ciclo: medir → hacer profile → encontrar el hotspot → arreglar una cosa → medir otra vez. Debajo, dos leyes que acotan tus expectativas._

#### Profiling (medir antes de optimizar)

- **Problema:** El equipo «acelera» el sitio equivocado: pasa una semana y el sistema no va más rápido.
- **Idea:** Un profile muestra dónde se va realmente el tiempo. Arregla solo el hotspot.
- **Ejemplo:** La «página lenta» resulta ser una consulta N+1, no un lenguaje lento: se arregla con una consulta y un join.
- **Coste:** Tiempo de medición y de herramientas; necesitas un perfil de carga reproducible.
- **Cuándo usarlo:** Antes de cualquier optimización. Sin profile, no hay optimización.
- **Relaciones:** La **Ley de Amdahl** es el techo de aceleración; la **Ley de Little** une latencia, throughput y colas.

> **La pregunta clave:** ¿Qué métrica se pone roja primero con carga real?

## 14. Escalabilidad sin reescribir

La escalabilidad es la capacidad de crecer en carga y en funcionalidades sin reconstruir el sistema desde cero.

### Vertical vs Horizontal Scaling — compran cosas distintas

> Puedes comprar un camión grande. Puedes comprar diez pequeños. El primero es más simple, los segundos más flexibles, pero requieren un despachador.

El **vertical scaling** (scale up) consiste en hacer más fuerte una máquina. Es simple mientras haya margen. El **horizontal scaling** (scale out) consiste en añadir más instancias. Es más flexible, pero requiere una capa de aplicación stateless, load balancing, una estrategia de estado compartido y observability.

Las bases de datos escalan peor que las aplicaciones. Las **read replicas** ayudan con las lecturas, no con las escrituras. El **sharding** reparte los datos pero te obliga a elegir una shard key. Una mala shard key convierte el escalado en un desequilibrio de carga.

_Diagram: Izquierda: una máquina crece hasta chocar con el techo del hardware. Derecha: un load balancer y muchas copias stateless idénticas. Debajo: dos formas de escalar la base de datos._

#### Vertical vs Horizontal Scaling (scale up / scale out)

- **Problema:** La carga crece y una sola máquina pronto no bastará.
- **Idea:** Vertical: hacer la máquina más fuerte. Horizontal: poner más máquinas detrás de un load balancer.
- **Ejemplo:** Una app stateless es fácil de multiplicar; la base de datos es más difícil: read replicas para lecturas, sharding por shard key para escrituras.
- **Coste:** Vertical choca con un techo. Horizontal necesita una capa stateless, load balancing, una estrategia de estado compartido y observability.
- **Cuándo usarlo:** Vertical mientras haya margen. Horizontal cuando necesitas crecer más allá.
- **Relaciones:** El eje X del **Scale Cube**; los componentes **stateless** del módulo de estado; **Single Source of Truth**.

### Scale Cube — escalar funcionalidades importa tanto como escalar carga

> Una ciudad no crece solo en población. Crece en escuelas, hospitales, carreteras y normas.

El sistema tiene que absorber no solo más tráfico, sino más superficie de producto. Si cada nueva funcionalidad exige reescribir un God-service compartido, el sistema no escala a nivel organizativo.

El modelo útil aquí es el **scaling cube**: el **eje X** es clonar, el **eje Y** es dividir por función, el **eje Z** es particionar por datos o tenants.

_Diagram: Tres ejes de crecimiento: X, copias de una misma app; Y, funciones distintas en partes distintas; Z, datos o clientes repartidos en particiones._

#### Scale Cube (ejes X / Y / Z)

- **Problema:** La gente solo piensa en el tráfico, pero el sistema se rompe por el crecimiento de funcionalidades: todo vive en un God-service.
- **Idea:** Crecer por tres ejes: X, clonar; Y, dividir por función; Z, dividir por datos o tenants.
- **Ejemplo:** X: tres copias de la app. Y: facturación, catálogo e identidad por separado. Z: tenants A–H en un shard, I–P en otro.
- **Coste:** Cada eje añade fronteras que hay que sostener y observar.
- **Cuándo usarlo:** Cuando preguntas «qué se rompe primero» y la respuesta no es solo la CPU.
- **Relaciones:** El eje Y es **Bounded Context** y microservicios; el eje Z es sharding; ojo con la **Conway's Law**.

> **La pregunta clave:** ¿Qué se rompe primero: la CPU, la base de datos, el equipo, los releases o el modelo de datos?

## 15. Fiabilidad ante el fallo

Un sistema fiable no es uno donde nada se rompe. Un sistema fiable sabe qué hacer cuando algo se rompe.

### Retry, Circuit Breaker, Bulkhead — un retry sin estrategia es un ataque contra ti mismo

> Si una puerta no se abre, llamar una vez es razonable. Llamar mil veces por segundo ya es un problema para la puerta y para los vecinos.

El **Retry** sirve para fallos transitorios. Pero los retries necesitan un límite, un timeout, **exponential backoff** y **jitter**. Si no, una caída parcial se convierte en una **retry storm**.

Un **circuit breaker** deja de llamar temporalmente a una dependencia atascada. El **bulkhead pattern** aísla recursos: si un downstream muere, no se lleva consigo todos tus threads de worker y pools de conexiones.

_Diagram: Arriba: retries con una pausa creciente y un desfase aleatorio. Abajo: pools separados (bulkheads) y un circuit breaker: una Payments API atascada no arrastra consigo a la búsqueda._

#### Retry + Circuit Breaker + Bulkhead (resistencia a dependencias que fallan)

- **Problema:** Una dependencia se ralentiza o muere; los retries sin cabeza la rematan y se comen todos los recursos del servicio.
- **Idea:** Retry con límite, timeout, backoff y jitter. Circuit breaker: dejar de llamar a lo que está muerto. Bulkhead: pools separados para que el fallo no se extienda.
- **Ejemplo:** La API de pagos se cuelga: el breaker se abre y falla rápido, mientras el pool de búsqueda sigue funcionando.
- **Coste:** Más ajustes y estados; hay que decidir cómo se degrada el sistema cuando una dependencia está caída.
- **Cuándo usarlo:** Cualquier llamada de red a algo que pueda colgarse.
- **Relaciones:** Los retries solo son seguros con **Idempotency**; ligado a **at-least-once** y **backpressure**.

### SLI / SLO / SLA — los SLOs convierten la fiabilidad en un contrato

> «Haremos lo posible» no es un horario de trenes. Un horario dice qué cuenta como normal y qué cuenta como fallo.

**SLI** es lo que mides: tasa de éxito, latencia, frescura. **SLO** es el objetivo: 99,9 % de peticiones exitosas en 30 días. **SLA** es una promesa al cliente con consecuencias.

El **error budget** te dice cuánta falta de fiabilidad puedes gastar. Si el presupuesto se agota, el equipo deja de perseguir funcionalidades y arregla la fiabilidad. Esa es la versión, en lenguaje de negocio, de la calidad de ingeniería.

_Diagram: El SLI es la medición, el SLO el objetivo, el SLA la promesa al cliente. Con un SLO del 99,9 % el error budget es el 0,1 %: unos 43 minutos por 30 días._

#### SLI / SLO / SLA (error budget)

- **Problema:** Nadie midió «fiable», así que la discusión funcionalidades-vs-calidad no termina nunca.
- **Idea:** Medir (SLI), acordar un objetivo (SLO), mantener aparte la promesa al cliente (SLA). La distancia hasta el 100 % es el error budget.
- **Ejemplo:** SLO: 99,9 % de peticiones exitosas en 30 días. Presupuesto agotado: las funcionalidades se pausan.
- **Coste:** Hay que elegir con honestidad qué medir y mantener la regla cuando se acaba el presupuesto.
- **Cuándo usarlo:** Cuando hay que hablar de fiabilidad con el negocio en un solo idioma.
- **Relaciones:** Los SLIs suelen construirse sobre la **Tail Latency**; las alertas saltan por **síntomas**; es un **NFR** en números.

> **La pregunta clave:** ¿Cómo se degrada el sistema cuando una dependencia no está disponible?

## 16. La seguridad como forma de vida

No se puede añadir seguridad justo antes del release. Tiene que estar incorporada al modelo de acceso, a los datos, a la infraestructura y a los procesos.

### Authentication vs Authorization — cosas distintas

> Un pasaporte prueba quién eres. Un billete prueba adónde puedes ir. Uno no sustituye al otro.

**Authentication** (AuthN) responde a «¿quién es?». **Authorization** (AuthZ) responde a «¿qué se le permite hacer?». Confundirlas es peligroso: un usuario puede haber iniciado sesión correctamente y aun así no tener derecho a leer la factura de otro.

**RBAC** concede permisos mediante roles. **ABAC** considera atributos: dueño del recurso, tenant, región, estado del objeto. La auth basada en sesión es más fácil de revocar; **JWT** es más fácil de verificar sin base de datos, pero más difícil de revocar. La elección depende de las amenazas y del ciclo de vida.

_Diagram: Una petición pasa por dos pasos distintos: authentication («¿quién eres?»: el pasaporte) y authorization («¿qué puedes hacer?»: el billete). Haber iniciado sesión no significa tener permiso._

#### Authentication vs Authorization (AuthN / AuthZ)

- **Problema:** «El usuario ha iniciado sesión» se confunde con «el usuario tiene permiso», y acaba leyendo datos ajenos.
- **Idea:** Dos pasos separados: AuthN establece la identidad, AuthZ comprueba el derecho a un recurso concreto.
- **Ejemplo:** Un cliente con sesión iniciada pide la factura #42 de otro cliente: AuthZ debe responder 403.
- **Coste:** Elegir un modelo: RBAC es más simple, ABAC más preciso; las sesiones se revocan fácil, los JWT se verifican fácil pero se revocan mal.
- **Cuándo usarlo:** En cualquier sistema donde los datos tengan dueño.
- **Relaciones:** Una capa de la **defense in depth**; las amenazas de spoofing y elevation of privilege de **STRIDE**.

### Threat Modeling — paranoia profesional

> Un buen arquitecto piensa como un atacante no porque desconfíe de la gente, sino porque confía en la realidad.

El **threat modeling** es una búsqueda sistemática de amenazas antes del ataque. **STRIDE** ayuda a encontrarlas: spoofing, tampering, repudiation, information disclosure, denial of service, elevation of privilege. La **defense in depth** significa varias capas de protección: validación de entrada, authz, cifrado, audit log, rate limiting, least privilege.

La **gestión de secretos** no es «poner la clave en env y olvidarse». Hay que entender la rotación, el acceso, la auditoría, el blast radius y qué pasa durante una fuga.

_Diagram: Izquierda: las seis clases de amenaza de STRIDE por las que pasar cada componente. Derecha: protección por capas; si una capa cae, las demás siguen en pie._

#### Threat Modeling (STRIDE, defense in depth)

- **Problema:** La seguridad se recuerda justo antes del release, cuando ya es tarde para cambiar el modelo de acceso.
- **Idea:** Pasar el componente por STRIDE y poner varias capas de protección, no una única cerradura «principal».
- **Ejemplo:** Una clave filtrada: qué abre (blast radius), qué tan rápido puedes rotarla, dónde aparece en la auditoría.
- **Coste:** Tiempo para la revisión y disciplina en la gestión de secretos.
- **Cuándo usarlo:** En el diseño de cada componente e integración nuevos.
- **Relaciones:** **AuthN vs AuthZ** es una capa de protección; la **observability** y el audit log permiten detectar un ataque.

> **La pregunta clave:** ¿Qué puede hacer un atacante si consigue acceso a este componente?

## 17. Observability y operaciones

No se puede arreglar lo que no se ve. El sistema tiene que explicar su propio estado sin arqueología en el código.

### Observability — el monitoring te dice qué falla, la observability te ayuda a entender por qué

> La luz de «check engine» es útil, pero el mecánico aún necesita indicadores, historial y herramientas de diagnóstico.

El **monitoring** responde a «algo va mal». La **observability** responde a «por qué». Los tres pilares de la observability: **logs**, **metrics**, **traces**. El structured logging permite consultar los logs. Las métricas muestran agregados. El **distributed tracing** sigue el camino de una petición por los servicios.

Un **correlation ID** es una cosita que salva noches: un único ID de petición fluye por gateway, servicio, cola, worker y downstream.

_Diagram: Tres pilares: logs, metrics, traces. Un correlation ID pasa por cada salto, así que se puede reconstruir todo el camino de la petición._

#### Observability (logs · metrics · traces, correlation ID)

- **Problema:** Algo se rompió de noche y la causa se busca con arqueología en el código.
- **Idea:** El sistema explica su propio estado: logs estructurados, métricas agregadas, traces del camino de la petición.
- **Ejemplo:** Con el request id `req-7f3a` encuentras la petición en el gateway, en la cola y en el worker, y ves dónde se atascó.
- **Coste:** Herramientas, almacenamiento de datos y la disciplina de pasar el ID a todas partes.
- **Cuándo usarlo:** Desde el primer día, sobre todo en un sistema distribuido con colas.
- **Relaciones:** La fuente de datos de los **SLIs** y del **Symptom-based Alerting**; sin ella, el **Profiling** va a ciegas.

### Symptom-based Alerting — alerta por síntomas

> Al usuario no le importa que la CPU esté al 92 %. Le importa que el checkout no funciona.

Una buena alerta habla del dolor del usuario; esto es el **symptom-based alerting**: tasa de errores, latencia, pagos fallidos, datos obsoletos. Una mala alerta habla de una causa que puede ser perfectamente normal. Si las alertas hacen ruido, el equipo deja de confiar en ellas.

Un **runbook** responde a «qué hacer a las 3 de la madrugada». Un **post-mortem** responde a «cómo nos aseguramos de que no vuelva a pasar». **Blameless**: el objetivo es mejorar el sistema, no encontrar al culpable.

_Diagram: Las causas, como la CPU, suelen ser normales y hacen ruido. Las alertas se construyen sobre síntomas de dolor del usuario, seguidas de un runbook y un post-mortem blameless._

#### Symptom-based Alerting (runbook, post-mortem blameless)

- **Problema:** Las alertas saltan por causas, el equipo se acostumbra al ruido y se le pasa una caída real.
- **Idea:** Despertar a una persona solo por dolor del usuario; cada alerta lleva su runbook.
- **Ejemplo:** No «CPU al 92 %», sino «subieron los pagos fallidos», más un runbook: qué comprobar primero.
- **Coste:** Hay que conocer tus síntomas y mantener los runbooks al día.
- **Cuándo usarlo:** Para todo lo que el ingeniero de guardia tiene que arreglar de noche.
- **Relaciones:** Los síntomas son **SLIs**; el post-mortem es la misma cultura escrita que los **ADRs** y los **RFCs**.

> **La pregunta clave:** Si esto se rompe de noche, ¿qué datos ayudarán a encontrar la causa en diez minutos?

## 18. Documentación que vive

Una decisión arquitectónica sin registrar desaparece junto con el contexto de su autor.

### ADR — un Architecture Decision Record vence a la memoria

> Un acuerdo oral vale hasta las primeras vacaciones, la primera renuncia o la primera discusión seis meses después.

Un **Architecture Decision Record** recoge el contexto, la decisión, las alternativas y las consecuencias. Un ADR no tiene que ser una novela. Un buen ADR responde: qué problema resolvíamos, qué elegimos, por qué no elegimos las alternativas, cuándo lo revisamos.

La documentación no está para la auditoría: está para el siguiente cambio. Un ingeniero nuevo tiene que entender no solo el «cómo», sino el «por qué».

_Diagram: Un ADR, una decisión: contexto, elección, alternativas, consecuencias y cuándo revisarla. Seis meses después una persona nueva conoce el «por qué»._

#### ADR (Architecture Decision Record)

- **Problema:** La decisión vivía en la cabeza del autor; el autor se fue y nadie sabe por qué se hizo así.
- **Idea:** Un registro corto por decisión: contexto, decisión, alternativas, consecuencias.
- **Ejemplo:** «Elegimos PostgreSQL, no MongoDB: necesitamos transacciones; se revisa si aparecen cargas de tipo documento.»
- **Coste:** Media hora de escritura. Más barato que la discusión seis meses después.
- **Cuándo usarlo:** Para decisiones caras de revertir.
- **Relaciones:** Registra **Trade-offs** y deuda; va junto al **RFC**; parte de **Learning in Public**.

### C4 Model — un diagrama es una herramienta de trabajo, no una decoración

> Un mapa de metro no muestra los cables ni los tornillos. Muestra líneas y transbordos. Eso basta para no perderse.

El **C4 model** te da cuatro niveles: **Context**, **Container**, **Component**, **Code**. Los tres primeros suelen bastar. Un **sequence diagram** es útil cuando importa el orden de las interacciones. El UML completo rara vez hace falta; los diagramas sueltos, sí.

La **living documentation** vive junto al código, se actualiza en el PR y se revisa. Un documento en un wiki olvidado se convierte enseguida en ficción histórica.

_Diagram: Los cuatro niveles de zoom de C4; suelen bastar tres. La documentación viva está junto al código; un wiki olvidado se convierte en ficción._

#### C4 Model (documentación viva)

- **Problema:** Los diagramas se dibujan para quedar bien: todo en una imagen, y un mes después miente.
- **Idea:** Dibujar por nivel de zoom: Context → Container → Component (→ Code, rara vez).
- **Ejemplo:** Context: el sistema, los usuarios, los servicios externos. Container: web, API, base de datos, cola.
- **Coste:** Los diagramas hay que actualizarlos en el mismo PR que el código.
- **Cuándo usarlo:** Cuando hay que explicar el sistema a una persona nueva o a otro equipo.
- **Relaciones:** Muestra los **Bounded Contexts** y las fronteras; un sequence diagram cubre el orden de las llamadas.

> **La pregunta clave:** ¿Podrá una persona nueva, dentro de seis meses, entender por qué lo hicimos así?

## 19. Comunicación y persuasión

El arquitecto habla con ingenieros, producto, negocio, seguridad y legal. Cada audiencia oye un idioma distinto.

### Risk Translation — traduce el riesgo al idioma de la audiencia

> Un médico no usa solo nombres en latín con el paciente. Explica qué va a doler, cuánto dura el tratamiento y qué hay que evitar.

Esta es la práctica de la **risk translation**. A un ingeniero le puedes decir: «no tenemos idempotencia en el callback de pago». El negocio necesita oír: «si el webhook reintenta, podemos cobrar dos veces o enviar el producto dos veces; es un riesgo financiero y de reputación».

El **stakeholder mapping** te ayuda a ver a quién le importa qué: producto quiere time-to-market, seguridad quiere reducir riesgo, finanzas quiere un coste predecible, soporte quiere un comportamiento comprensible, ingeniería quiere mantenibilidad.

_Diagram: El mismo riesgo suena distinto para los ingenieros y para el negocio. El mapa de stakeholders muestra qué importa a cada uno._

#### Risk Translation (stakeholder mapping)

- **Problema:** Un riesgo técnico suena a jerga y el negocio no lo oye.
- **Idea:** Traducir el riesgo a consecuencias que importan a esta audiencia concreta.
- **Ejemplo:** «Sin idempotencia en el callback» → «podemos cobrar dos veces: un riesgo financiero y de reputación».
- **Coste:** Hay que saber qué le importa a cada stakeholder y hablar su idioma.
- **Cuándo usarlo:** Cada vez que una decisión depende de gente ajena a ingeniería.
- **Relaciones:** El ejemplo es **Idempotency**; el lado de negocio son los **NFRs** y el **cost of delay**.

### RFC — una propuesta escrita baja la temperatura de una discusión

> Una discusión en la pizarra suele ganarla el que más grita. Una propuesta escrita obliga a que los argumentos se sostengan aparte de la voz.

Un **RFC** (Request for Comments) describe el problema, las restricciones, las opciones, la solución elegida, los riesgos y el plan de despliegue. Un buen RFC invita a la crítica antes de que la decisión se convierta en norma.

**Disagree and commit** solo funciona después de una discusión honesta. Si no se escuchó al equipo, eso no es commit: es supresión.

_Diagram: Las secciones de un RFC y el camino de una decisión: borrador → revisión con críticas → decidir → disagree and commit, pero solo si todos fueron escuchados._

#### RFC (Request for Comments, disagree and commit)

- **Problema:** La discusión en la pizarra la gana el que más grita, no el que más razón tiene.
- **Idea:** Por escrito: problema, restricciones, opciones, decisión, riesgos, despliegue. La crítica llega antes de la decisión.
- **Ejemplo:** Antes de pasar a una cola nueva: un RFC, una semana de comentarios, luego una decisión y un ADR.
- **Coste:** Más lento que «decidir en una llamada»; necesita un responsable que lo lleve hasta una decisión.
- **Cuándo usarlo:** Para decisiones que afectan a varios equipos o son caras de revertir.
- **Relaciones:** El resultado va a un **ADR**; una herramienta de **Influence without Authority**.

> **La pregunta clave:** ¿Cómo le explico esta decisión a alguien que no comparte mis prioridades técnicas?

## 20. Liderazgo sin autoridad

El arquitecto suele seguir siendo un contribuidor individual. Su autoridad viene de la claridad de pensamiento, la confianza y la capacidad de hacer más fuerte al equipo.

### Influence without Authority

> Un director de orquesta no toca todos los instrumentos, pero sin él la orquesta pronto se convierte en un conjunto de talentos que tocan piezas distintas.

Este es el concepto de **influence without authority**. El arquitecto no debe convertirse en un cuello de botella para cada decisión. Su trabajo es fijar principios, explicar fronteras, hacer crecer a la gente e intervenir donde el coste de un error es alto.

El **mentoring** de un arquitecto no es «haz lo que yo hago». Es enseñar las preguntas: qué alternativas has visto, a qué renunciaste, cómo vas a probar el riesgo, dónde termina la responsabilidad.

_Diagram: Izquierda: el arquitecto como cuello de botella; cada decisión espera en la cola. Derecha: un multiplicador; principios, fronteras y preguntas, mientras los equipos deciden._

#### Influence without Authority (mentoring con preguntas)

- **Problema:** El arquitecto decide todo personalmente y se convierte en una cola para cada equipo.
- **Idea:** Influir mediante principios, fronteras y preguntas, no con órdenes.
- **Ejemplo:** En lugar de «hazlo así»: «¿qué alternativas viste y cómo vas a probar el riesgo?»
- **Coste:** Más lento en el momento; necesita una confianza que lleva años construir.
- **Cuándo usarlo:** Siempre que no tengas subordinados directos pero aun así haya que tomar decisiones.
- **Relaciones:** Funciona a través de **RFCs** y **ADRs**; lo opuesto es el **Ivory Tower Architect**.

### Delegation with Guardrails — delegar no es transferir la responsabilidad

> Un capitán puede ceder el timón, pero no puede decir que el rumbo del barco ya no es asunto suyo.

Una parte de las decisiones arquitectónicas deben tomarlas los equipos. Si no, el arquitecto se convierte en una cola. Pero tiene que haber **guardrails**: principios, revisión, ADRs, restricciones de plataforma, quality gates.

El arquitecto interviene cuando una decisión es irreversible, rompe invariantes del sistema, crea riesgo de seguridad o afecta a varios equipos.

_Diagram: El equipo decide por su cuenta dentro de los guardrails. El arquitecto interviene solo ante las cuatro señales de la derecha._

#### Delegation with Guardrails (la responsabilidad se queda)

- **Problema:** O todo pasa por el arquitecto (una cola), o nadie es dueño del rumbo.
- **Idea:** Los equipos deciden por su cuenta dentro de los guardrails; el arquitecto es dueño del rumbo e interviene ante señales claras.
- **Ejemplo:** El equipo elige su librería de logging; cambiar el modelo de tenancy solo se hace con el arquitecto.
- **Coste:** Los guardrails hay que formularlos, escribirlos y comprobarlos automáticamente cuando se pueda.
- **Cuándo usarlo:** Cuando hay más de un equipo y un solo arquitecto.
- **Relaciones:** La señal «irreversible» viene de **Reversible vs Irreversible**; los guardrails son **ADRs** y quality gates.

> **La pregunta clave:** ¿Estoy amplificando la capacidad del equipo para tomar decisiones o me estoy poniendo en su lugar?

## 21. Negocio y producto

La arquitectura solo tiene sentido en el contexto de un objetivo de negocio. Si no, es estética de ingeniería cara.

### Non-functional Requirements — también son requisitos de negocio

> Para una tienda, «el checkout funciona en el Black Friday» no es un detalle técnico: es dinero.

Los **non-functional requirements** (NFRs) —rendimiento, disponibilidad, seguridad, compliance, operabilidad— no son «caprichos técnicos». Son propiedades del producto. El arquitecto los traduce a impacto de negocio: ingresos perdidos, riesgo regulatorio, coste de soporte, velocidad de lanzamiento al mercado.

El **cost of delay** te ayuda a hablar no solo del coste de hacer el trabajo, sino del coste de esperar. A veces hace falta una inversión arquitectónica sin ROI inmediato, porque sin ella las siguientes funcionalidades empiezan a salir más caras.

_Diagram: Izquierda: los requisitos no funcionales. Derecha: en qué se convierten para el negocio. El arquitecto es el traductor del medio._

#### Non-functional Requirements (NFRs, cost of delay)

- **Problema:** La calidad del sistema se trata como un «capricho técnico» y se sigue posponiendo.
- **Idea:** Los NFRs son propiedades del producto; háblalos en ingresos, riesgo y coste.
- **Ejemplo:** «El checkout sobrevive al Black Friday» es dinero, no un detalle.
- **Coste:** Hay que estimar el impacto en números, aunque sea a grandes rasgos.
- **Cuándo usarlo:** Cuando el trabajo arquitectónico compite con las funcionalidades por el tiempo.
- **Relaciones:** En números: **SLOs**; el trabajo pospuesto: **Technical Debt**; el idioma: **Risk Translation**.

### Build vs Buy — no es cuestión de orgullo

> No toda empresa debería construir su propia central eléctrica solo para encender la luz.

**Construir** te da control y diferenciación. **Comprar** te da velocidad y reduce la carga operativa. El **vendor lock-in** es un riesgo real, pero por sí solo no es un argumento contra comprar. La pregunta: ¿cuánto cuesta salir si el proveedor cambia el precio, la API o la calidad?

El arquitecto ayuda a producto a ver el **capability map**: qué capacidades son el núcleo del negocio y cuáles conviene comprar.

_Diagram: Construye el núcleo por el que los clientes te pagan; compra lo commodity. Para todo lo que compres, la pregunta clave es el coste de salida._

#### Build vs Buy (capability map, vendor lock-in)

- **Problema:** Se construye por orgullo, o se compra todo sin plan de salida.
- **Idea:** Construir lo que diferencia al negocio; comprar lo commodity. Para todo lo comprado, estimar el coste de salida.
- **Ejemplo:** Tu propio motor de dominio: construir; envío de email o pagos: normalmente comprar.
- **Coste:** Construir: tiempo y mantenimiento para siempre. Comprar: dependencia del precio, la API y la calidad del proveedor.
- **Cuándo usarlo:** Antes de cada «escribamos el nuestro».
- **Relaciones:** La trampa es el **síndrome NIH**; **Dependency Inversion** ayuda a aislar al proveedor.

> **La pregunta clave:** ¿Cómo cambia esta decisión arquitectónica la velocidad, el riesgo o el coste del negocio?

## 22. El arquitecto AI-native

Cuando el código lo escriben agentes, el valor del arquitecto se desplaza hacia la especificación, el pensamiento arquitectónico y el control de calidad.

### Specification-driven Development — la calidad de la spec se convierte en el cuello de botella

> Si la cuadrilla de obra se vuelve diez veces más rápida, la restricción que manda deja de ser la velocidad de los ladrillos. Pasa a ser la calidad de los planos.

Los agentes de IA aceleran la implementación, pero no eliminan la arquitectura. Una tarea mal planteada simplemente se convierte en mal código más rápido. **Specification-driven development** significa que el artefacto principal es la especificación de comportamiento, fronteras, invariantes, tests y criterios de aceptación.

En un proceso AI-native, el arquitecto escribe menos código de bajo nivel y más prosa precisa. Revisa el diff, los tests, las fronteras arquitectónicas y la alineación con la spec.

_Diagram: La spec es el artefacto principal. El agente la convierte rápido en código; el arquitecto comprueba el código contra la spec y, si hay fallo, corrige la spec._

#### Specification-driven Development (la spec como artefacto principal)

- **Problema:** Un agente escribe código diez veces más rápido, y construye lo equivocado igual de rápido.
- **Idea:** El artefacto principal es la spec: comportamiento, fronteras, invariantes, tests, criterios de aceptación.
- **Ejemplo:** En lugar de «construye pagos»: escenarios, errores, la invariante «un pago por pedido» y tests para ella.
- **Coste:** El arquitecto escribe prosa más precisa y menos código.
- **Cuándo usarlo:** Siempre que un agente de IA haga la implementación.
- **Relaciones:** Lo comprueba **Agent Output Review**; las invariantes salen del **API Contract** y del **Bounded Context**.

### Agent Output Review — el código de un agente merece la misma disciplina que el PR de una persona

> Un junior rápido que escribe mil líneas por hora sigue necesitando revisión. La velocidad no hace correcto al código.

No puedes aceptar el código de un agente solo porque compila. Hacen falta tests, evals, fronteras de import, comprobaciones de tipos, revisión de seguridad. Las **scenario evaluations** importan especialmente: el sistema tiene que pasar casos reales, no solo el happy path.

Una organización AI-native gana no donde «todos hacen vibe-coding», sino donde hay especificaciones sólidas, iteraciones pequeñas, comprobaciones automatizadas y responsabilidad arquitectónica.

_Diagram: El PR de un agente pasa por los mismos quality gates que el de una persona: tests, scenario evals, fronteras de import, tipos, revisión de seguridad._

#### Agent Output Review (quality gates para código de IA)

- **Problema:** El código del agente se acepta porque compila y suena seguro de sí mismo.
- **Idea:** Los mismos quality gates automatizados y la misma revisión que para una persona.
- **Ejemplo:** Las scenario evals detectan que el agente solo trató el happy path y olvidó el pago repetido.
- **Coste:** Hay que construir de antemano las comprobaciones automáticas y las fronteras de import.
- **Cuándo usarlo:** Cada PR de un agente, sin excepciones.
- **Relaciones:** Comprueba la alineación con **Specification-driven Development**; las fronteras vienen de **Dependency Inversion**.

> **La pregunta clave:** ¿La especificación es lo bastante precisa para que un ejecutor rápido no construya lo equivocado?

## 23. Los antipatrones del arquitecto

El arquitecto puede ser peligroso justamente porque suena convincente. Conocer las trampas ahorra años.

### Ivory Tower Architect

> Alguien dibuja una ciudad perfecta en lo alto de la colina, pero nunca baja a ver por dónde camina la gente en realidad.

Este es el antipatrón del **ivory tower architect**: decisiones tomadas lejos del código, de la operación y del equipo. Los diagramas son preciosos, pero la implementación sufre. La cura es simple: leer PRs, mirar incidentes, hablar con los ingenieros, recorrer tú mismo el camino de un cambio.

_Diagram: La torre está lejos del suelo: del código, de los incidentes y de los ingenieros. La cura es bajar: leer PRs, mirar incidentes, hablar, recorrer el camino de un cambio._

#### Ivory Tower Architect (arquitectura desde la colina)

- **Síntoma:** Diagramas preciosos que el equipo no puede implementar.
- **Por qué duele:** Las decisiones ignoran el código real, la operación y a las personas.
- **Cura:** Leer PRs, mirar incidentes, hablar con los ingenieros, recorrer tú mismo el camino de un cambio.
- **Relaciones:** Lo opuesto a **Influence without Authority**; la forma por encima de la realidad es también **Cargo Cult**.

### Resume-driven Development y Cargo Cult

> Comprar un camión de bomberos porque impresiona a los vecinos es raro si no tienes agua ni bomberos.

El **resume-driven development** elige tecnologías por una línea en el CV. La **cargo cult engineering** copia la forma de la decisión de otro sin su razón. El **síndrome NIH** (Not Invented Here) te obliga a escribir lo tuyo donde una herramienta externa madura lo haría mejor.

Otra trampa es el **technical perfectionism**. La arquitectura perfecta que nunca llegó al usuario pierde frente a un sistema suficientemente bueno que se entrega y puede evolucionar.

_Diagram: Cuatro trampas que te alejan del problema real: tecnología para el CV, copiar la forma, «construyamos el nuestro» y pulir sin fin._

#### Resume-driven Development (cargo cult, NIH, perfeccionismo)

- **Síntoma:** La decisión se justifica por la moda, el ejemplo de otro o la belleza, no por un problema.
- **Por qué duele:** Pagas el precio de una tecnología compleja sin su beneficio, o nunca llegas al usuario.
- **Ejemplo:** Kubernetes y microservicios para un equipo de tres, «porque lo hace Netflix».
- **Cura:** Partir del problema y nombrar con honestidad el precio de cada opción.
- **Relaciones:** Se cura con **Trade-offs** y **Build vs Buy**; a menudo produce un **Distributed Monolith**.

> **La pregunta clave:** ¿Estoy eligiendo esta decisión por el problema o por la sensación de belleza arquitectónica?

## 24. Crecimiento continuo

La arquitectura es un juego infinito. Las tecnologías cambian, pero la capacidad de hacer las preguntas correctas solo se fortalece.

### T-shaped / M-shaped Skills — aprende de los sistemas, no del hype

> Un cocinero no crece mirando anuncios de cuchillos, sino entendiendo los ingredientes, el calor, el tiempo y el sabor.

Vale la pena estudiar las tecnologías nuevas mediante preguntas: qué problema resuelven, qué precio introducen, dónde han fallado ya, cuáles son las alternativas, qué tiene que ser cierto para que resulten útiles.

_Diagram: Cinco preguntas de filtro para cualquier tecnología nueva. Después decides: adoptarla ya o esperar._

Las **T-shaped skills** te dan profundidad en un área y amplitud en las vecinas. Las **M-shaped skills** aparecen en un arquitecto maduro: varios pilares profundos: datos, distribución, seguridad, producto, herramientas de IA.

_Diagram: T: un área profunda más amplitud. M: varios pilares profundos en un arquitecto maduro._

#### T-shaped / M-shaped Skills (aprender de los sistemas, no del hype)

- **Problema:** La gente aprende cada tecnología de moda, pero no gana profundidad ni criterio.
- **Idea:** Estudiar las tecnologías mediante preguntas sobre el problema y el precio; cultivar varios pilares profundos.
- **Ejemplo:** Una base de datos nueva: qué problema resuelve, dónde ha fallado ya, qué tiene que ser cierto para que nos ayude.
- **Coste:** Más lento que leer anuncios; la profundidad lleva años.
- **Cuándo usarlo:** Con cada tecnología nueva que aparezca en el radar.
- **Relaciones:** Una defensa contra el **Resume-driven Development**; los pilares son los temas de este curso.

### Learning in Public — acelera la madurez

> Cuando explicas una decisión por escrito, los huecos de tu pensamiento aparecen antes de que los encuentre producción.

**Learning in public** significa aprender abiertamente, por escrito. Escribe ADRs, RFCs, notas de ingeniería, post-mortems, desgloses breves de decisiones. Aprende de arquitectos más fuertes que tú: no solo qué eligieron, sino cómo razonaron.

El arquitecto al que la gente imita normalmente no es el que más términos conoce. Es la persona junto a la cual el equipo empieza a hacer mejores preguntas.

_Diagram: El ciclo: decidir → escribirlo → recibir feedback → hacer mejores preguntas. Los huecos de tu pensamiento aparecen antes que en producción._

#### Learning in Public (aprender por escrito)

- **Problema:** Producción encuentra los fallos de tu razonamiento antes que tus colegas.
- **Idea:** Escribir las decisiones y los desgloses, compartirlos, aprender del feedback.
- **Ejemplo:** ADRs, RFCs, notas de ingeniería, post-mortems, desgloses breves de decisiones.
- **Coste:** Tiempo para escribir, y el coraje de enseñar un pensamiento sin terminar.
- **Cuándo usarlo:** Todo el tiempo: así crece un arquitecto.
- **Relaciones:** Usa **ADRs**, **RFCs** y **post-mortems**; hace más fuerte al equipo, igual que **Influence without Authority**.

> **La última pregunta:** ¿Qué preguntas me hago ahora antes de abrir el editor?

#### Autoevaluación final

- Puedo nombrar los trade-offs de una decisión sin defender mi ego.
- Entiendo dónde vive la fuente de la verdad en el sistema.
- Distingo las decisiones reversibles de las irreversibles.
- Puedo explicar la arquitectura a ingeniería, producto y negocio con palabras distintas.
- Escribo las decisiones de modo que se puedan entender aún dentro de un año.
- No escondo la complejidad detrás de las palabras «best practice».

### El mapa del curso: cómo se conecta todo

> Un mapa de metro al final del viaje: ahora ves dónde se cruzan las líneas.

La mentalidad da forma a la estructura, a los datos y a la calidad. La estructura se registra en documentos, la calidad se verifica con seguridad y operaciones, y los documentos y los riesgos convencen al negocio. Todo junto escala hacia el trabajo AI-native y el crecimiento personal.

_Diagram: Los ocho grupos de conceptos del curso y cómo se conectan: de la mentalidad a la estructura, los datos y la calidad, y de ahí a documentos, negocio, operaciones y crecimiento._

## Chuleta: los 52 conceptos del curso

### La mentalidad del arquitecto (1–4)

- **Long-term Thinking** (pensar en años): Primero comprueba si el problema está bien planteado y cómo vivirá la decisión dentro de tres años.
- **Reversible vs Irreversible** (dos tipos de decisiones): Decide rápido lo que es fácil de deshacer; despacio lo que cambia la trayectoria del sistema.
- **Trade-offs** (un intercambio deliberado): Cada elección compra una propiedad a costa de otra. Una buena práctica sin contexto es un mal consejo.
- **Over- / Under-engineering** (la complejidad es un impuesto): La complejidad se justifica solo cuando compra una propiedad importante. Mantén el punto medio.
- **Technical Debt** (un préstamo, no basura): Una decisión que te acelera ahora y cuesta más después.
- **Debt Interest** (la ralentización): La ralentización de cada cambio siguiente. La deuda en la zona caliente es la que más cuesta.
- **Cognitive Load** (cabe en una cabeza): Cuánto contexto necesitas para cambiar un componente con seguridad. Quita la complejidad accidental.
- **Conway's Law** (forma de la org = forma del sistema): Un sistema refleja la estructura de comunicación de la organización.

### Estructura del sistema (5–7, 11)

- **Cohesion & Coupling** (una sola cosa dentro, poco hacia fuera): Dentro de un componente, todo trata de una sola cosa; hacia fuera, saber lo mínimo de los demás.
- **Bounded Context** (frontera de DDD): Una frontera dentro de la cual las palabras tienen un solo significado.
- **Dependency Inversion** (las dependencias apuntan hacia dentro): La lógica de negocio depende de abstracciones; los detalles se enchufan desde fuera (ports and adapters).
- **Abstraction** (existe para absorber el cambio): Una capa se gana su sitio absorbiendo el cambio y permitiendo probar sin el mundo exterior, no quedando bonita.
- **API Contract** (el contrato por encima del transporte): Esquema, errores, versionado y compatibilidad importan más que REST vs GraphQL vs gRPC.
- **Idempotency** (seguro de repetir): Repetir una operación da el mismo efecto final. Protección contra retries y duplicados.
- **Modular Monolith** (un despliegue, muros fuertes): Una aplicación con fronteras internas estrictas. A menudo, el mejor comienzo.
- **Distributed Monolith** (lo peor de ambos mundos): Servicios que solo se entregan juntos. El coste de la distribución sin la independencia.
- **Strangler Fig** (migrar pieza a pieza): Hacer crecer el sistema nuevo alrededor del viejo y mover el tráfico poco a poco, en lugar de una reescritura big-bang.

### Datos y distribución (8–10, 12)

- **Data Model** (los datos sobreviven al código): La decisión más cara: normalización, OLTP vs OLAP.
- **Event Sourcing** (el log de eventos es la verdad): El estado se reconstruye a partir de eventos: historial completo y auditoría, pero caro de operar y evolucionar.
- **CQRS** (separar modelos de escritura y lectura): Los comandos y las consultas tienen cada uno su modelo; útil cuando lecturas y escrituras difieren mucho.
- **Single Source of Truth** (una versión autorizada): De cada hecho sabes dónde vive la versión primaria; el resto son copias derivadas.
- **Cache Invalidation** (una segunda verdad que miente): Velocidad a costa de frescura; la pregunta difícil es cuándo invalidar.
- **Optimistic vs Pessimistic Locking** (comprobar al escribir vs bloquear antes): Dos formas de evitar que ediciones concurrentes se pisen entre sí.
- **CAP / PACELC** (la red es incertidumbre): Durante una partición: consistencia o disponibilidad; si no: latencia o consistencia.
- **Consistency Models** (strong, eventual, causal): No el modelo más estricto, sino el suficiente para el riesgo.
- **Saga** (una cadena de pasos con compensaciones): Una transacción larga entre servicios, donde cada paso tiene un deshacer en lugar de un bloqueo global.
- **Queue vs Pub/Sub** (no es solo «luego»): Async desacopla en el tiempo, pero trae retrasos, duplicados y problemas de orden.
- **At-least-once Delivery** (exactly-once es marketing): Un mensaje puede llegar dos veces; el consumidor debe ser idempotente. DLQ, backpressure.

### Calidad del sistema (13–15)

- **Tail Latency** (p95 / p99): Los usuarios sienten la cola, no el promedio.
- **Profiling** (medir primero): Optimiza solo el hotspot que encontraste; Amdahl y Little fijan los límites.
- **Vertical vs Horizontal Scaling** (scale up / scale out): Una máquina grande, o muchas idénticas detrás de un load balancer.
- **Scale Cube** (X / Y / Z): Clonar, dividir por función, dividir por datos.
- **Retry + Circuit Breaker + Bulkhead** (resistencia): Retries con backoff y jitter, un breaker para dependencias muertas, pools aislados.
- **SLI / SLO / SLA** (error budget): Medición, objetivo y promesa; el error budget decide entre funcionalidades y fiabilidad.

### Seguridad y operaciones (16–17)

- **Authentication vs Authorization** (AuthN / AuthZ): «¿Quién eres?» y «¿qué puedes hacer?» son dos pasos distintos.
- **Threat Modeling** (STRIDE, defense in depth): Encontrar las amenazas antes del ataque y defenderse por capas.
- **Observability** (logs · metrics · traces): El sistema explica el «por qué»; un correlation ID une todo el camino.
- **Symptom-based Alerting** (runbook, post-mortem): Alerta por el dolor del usuario; un runbook dice qué hacer; los post-mortems son blameless.

### Documentos y comunicación (18–19)

- **ADR** (Architecture Decision Record): Contexto, decisión, alternativas, consecuencias: uno por decisión.
- **C4 Model** (documentación viva): Diagramas por nivel de zoom que viven junto al código.
- **Risk Translation** (stakeholder mapping): Un riesgo, palabras distintas para ingenieros y para el negocio.
- **RFC** (disagree and commit): Una propuesta escrita, con crítica antes de la decisión.

### Liderazgo y negocio (20–21)

- **Influence without Authority** (mentoring): Principios, fronteras y preguntas en lugar de órdenes.
- **Delegation with Guardrails** (la responsabilidad se queda): Los equipos deciden; el arquitecto interviene ante irreversibilidad, invariantes, seguridad e impacto en varios equipos.
- **Non-functional Requirements** (NFRs, cost of delay): Propiedades del producto expresadas en ingresos, riesgo y coste.
- **Build vs Buy** (capability map): Construye el núcleo, compra lo commodity, conoce el coste de salida.

### AI-native, trampas y crecimiento (22–24)

- **Specification-driven Development** (la spec como artefacto): Cuanto más rápido el ejecutor, más importa la precisión de la spec.
- **Agent Output Review** (quality gates): El código de un agente pasa las mismas comprobaciones que el PR de una persona.
- **Ivory Tower Architect** (arquitectura desde la colina): Decisiones tomadas lejos del código, de la operación y del equipo.
- **Resume-driven Development** (cargo cult, NIH, perfeccionismo): Tecnología para el CV, copiar la forma, construir lo que deberías comprar, pulir sin fin.
- **T-shaped / M-shaped Skills** (aprender de los sistemas): Profundidad más amplitud; un arquitecto maduro tiene varios pilares profundos.
- **Learning in Public** (aprender por escrito): Escribe las decisiones y ve los huecos de tu pensamiento antes que producción.

> Un arquitecto es un ingeniero que aprendió a ver las consecuencias antes de que se convirtieran en un incidente.

Fin del curso · 24 módulos · la práctica empieza aquí.

Vuelve a leer este curso no como una referencia, sino como un conjunto de preguntas. La arquitectura empieza donde te detienes ante una decisión y nombras con honestidad el precio de cada opción.