Curso exprés · No. 02
No es un cargo, ni un título, ni el resultado de un examen. Es una manera de mirar un problema en el que la decisión de hoy define los próximos tres años.
Solo la esencia · Los detalles, por tu cuenta · Imágenes antes que definiciones
Lo que separa al arquitecto del ingeniero. No es conocimiento — es una manera de ver el problema.
El arquitecto mira diez años hacia adelante
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.
El arquitecto responde por las consecuencias, no por el código
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.
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. Por eso 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.
El arquitecto duda de la tarea, no solo de 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 te dicen «hacé X», el ingeniero pregunta «cómo hago X». El arquitecto pregunta «para qué hace falta X, y si otra cosa no resolvería mejor el problema de fondo». Con frecuencia la tarea está mal planteada — y la solución que te encargaron se vuelve, un año después, el problema.
El ingeniero hace bien la cosa. El arquitecto hace la cosa correcta.
La arquitectura es el arte de elegir qué perder. No existen soluciones perfectas.
Toda decisión gana algo y pierde algo
La bicicleta es más rápida que caminar, pero te mojás 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.
La solución simple casi siempre es más correcta que la compleja
La navaja suiza hace de todo, mal. Un buen cuchillo corta mejor que todos sus parientes apretados dentro de la navaja.
El ingeniero teme dejar fuera un requisito y mete en el sistema todo lo que podría llegar 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, la que se cambia fácil.
Las decisiones difíciles de deshacer merecen más atención
En un restaurante podés devolver el pedido. En una boda no podés devolver el «sí».
No todas las decisiones arquitectónicas cuestan lo mismo cuando se equivocan. Elegir un lenguaje de programación o una base de datos es casi irreversible. Elegir una librería de logging es reversible en un día. El arquitecto gasta un tiempo desproporcionado en las decisiones irreversibles y se mueve rápido en las reversibles.
La deuda técnica es una elección consciente, no pereza
Un préstamo para el negocio está bien si sabés cuándo y con qué lo vas a pagar. Un préstamo sin plan de devolución es el camino a la quiebra.
A veces lo correcto ahora es entregar algo que después habrá que reescribir. Eso es normal. Lo que no es normal es no reconocer que es deuda. El arquitecto deja por escrito qué trade-offs se aceptaron, por qué, y cuándo hay que revisarlos.
Cómo descomponer un problema grande en componentes que se puedan entender, cambiar y reemplazar por separado.
La descomposición es la habilidad central del arquitecto
No podés comerte una ballena entera. Sí podés — si la cortás en pedazos que entren en la boca.
Un sistema grande es inabarcable. 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 está mal.
Alta cohesión adentro, bajo acoplamiento afuera
Un buen departamento: la cocina está organizada alrededor de una idea (la hornalla al lado de la pileta), y con los vecinos comparte solo una pared.
Dentro de un módulo, todo debe ir sobre el mismo tema. Entre módulos, mínimo contacto, a través de una interfaz clara. Si cambiás algo en un módulo y tenés que tocar cinco más — el acoplamiento entre ellos es demasiado alto.
Las capas tratan sobre 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 podés poner los cimientos sobre el tercer piso.
En una buena arquitectura, la lógica de negocio no conoce la base de datos, ni la interfaz web, ni el framework. Las capas internas no dependen de las externas. Cuando hay que cambiar la base de datos o el framework, la lógica de negocio queda intacta. Eso es Clean Architecture en una frase.
La interfaz importa más que la implementación
No te importa de qué marca es el ascensor del edificio. Te importa que los botones funcionen igual, que las puertas abran de manera confiable y que sea silencioso.
Cuando un módulo se comunica con otro, lo que importa es el contrato entre ambos, no cómo está construido el otro por dentro. Primero se diseña el boundary (API, interfaz de clase, schema de mensaje); después, la implementación. La implementación se cambia con libertad; el contrato, solo con plena conciencia del costo.
Monolith o microservices — cuestión de madurez, no de moda
Un cocinero en una cocina chica saca un plato más rápido que diez cocineros negociando por Slack. Cien platos por hora, los diez cocineros los hacen mejor.
Los microservices resuelven problemas de escala organizacional y de carga, no de calidad del código. Un equipo chico con microservices es complejidad que nadie pidió. El arquitecto empieza con un monolith y lo divide cuando aparece el dolor real, no «porque está de moda».
La parte más duradera del sistema. Los patrones de código se reescriben; el modelo de datos vive años.
El modelo de datos sobrevive a todo lo demás
Los cimientos de una casa duran más que todas las paredes y techos que se levantan sobre ellos a lo largo de un siglo.
Los lenguajes se irán, los frameworks cambiarán, la interfaz se redibujará diez veces. La estructura de datos definida al inicio va a seguir viva — porque cambiarla sobre un sistema en producción es muy caro. Es lo primero a lo que el arquitecto dedica tiempo, y lo último que se apura en fijar.
Source of truth — cada hecho vive en un solo lugar
Si en la familia cada uno tiene su propia lista de compras, dos van a comprar leche y nadie va a comprar pan.
La misma información en dos lugares es un camino garantizado a la divergencia. El arquitecto define dónde vive cada hecho del sistema. Si los datos se duplican (por velocidad, por ejemplo), hay que dejar explícito qué es source of truth y qué es cache o proyección.
El estado es complejidad; cuanto menos, mejor
Un escritorio limpio hace más fácil el trabajo. Uno saturado te obliga a recordar dónde está cada cosa y te distrae constantemente.
Cada pedazo de estado guardado en algún lado es algo que se puede desincronizar, perder o contradecir a otro estado. Una buena arquitectura apunta a funciones sin memoria y variables con vida corta. El estado se deja donde realmente hace falta — habitualmente, en la base de datos.
Las transacciones tratan sobre la atomicidad de la intención
Una transferencia de dinero son dos acciones, pero una sola intención. O pasaron las dos escrituras, o ninguna. La mitad es una catástrofe.
Cuando varios cambios deben ocurrir como una unidad, hacen falta transacciones. El arquitecto sabe qué operaciones del sistema son atómicas, cuáles pueden fallar parcialmente y cómo convivir con eso. En sistemas distribuidos esto se vuelve el problema central (two-phase commit, sagas, idempotency).
El cache es una segunda verdad, y puede mentir
El calendario en la heladera es más rápido que mirar el teléfono. Pero si alguien cambió el plan en el teléfono — la heladera ya está mintiendo.
El cache da velocidad, pero te saca la garantía de frescura. El arquitecto siempre tiene claro: qué está cacheado, por cuánto tiempo y qué pasa si el cache miente. La pregunta más difícil sobre caching no es cómo agregar uno, sino cómo invalidarlo.
Los problemas más grandes no nacen dentro de los componentes, sino entre ellos.
Un boundary del sistema es un contrato, no código
La frontera entre países no es una reja — son las reglas: qué se puede cruzar, quién puede entrar, qué pasaporte hace falta.
Una API, un schema de mensaje, un formato de archivo — son una promesa frente a todo el que los usa. Cambiar el contrato es cambiar la promesa, y eso sale caro. Un buen arquitecto diseña contratos de manera que se puedan extender sin romper a los clientes existentes (agregar campos, nunca quitarlos).
Síncrono o asíncrono — una elección de acoplamiento
Una llamada telefónica: los dos lados tienen que estar en línea al mismo tiempo. Una carta: el destinatario la lee cuando puede.
Una llamada síncrona acopla dos servicios en el tiempo: si el receptor está caído, el emisor también se frena. Una cola de mensajes rompe ese acoplamiento: el emisor deja la carta y sigue. Eso te da resiliencia, pero suma complejidad: latencia, duplicados, orden.
Idempotency — una operación se puede repetir con seguridad
El ascensor fue llamado al tercer piso. Si diez personas vuelven a apretar el mismo botón, el ascensor igual va al tercero y nada se rompe.
En los sistemas reales, las llamadas se reintentan: por timeouts, fallas de red, reinicios. Una operación peligrosa de repetir es una bomba de tiempo. El arquitecto vuelve idempotentes por defecto a las operaciones críticas (pagos, procesamiento de mensajes).
Las dependencias externas son siempre un riesgo
Si la cena depende de la pizzería de enfrente — no hay drama, hay opciones de respaldo. Si depende del único proveedor de carne del pueblo — crítico.
Todo sistema externo (API, servicio, librería) puede caerse, ponerse lento o cambiar su contrato. El arquitecto decide qué pasa cuando eso ocurra: ¿cae el sistema entero o sigue funcionando con degradación? Muchas veces conviene aislar la dependencia externa detrás de una capa propia — para poder reemplazarla después.
No «qué hace el sistema», sino «qué tan bien lo hace». Lo que el cliente nunca va a formular, pero que va a exigir sí o sí.
La seguridad no es una feature, es la forma de vivir del sistema
En un museo, la seguridad no es una sola cámara en la entrada — son capas: molinetes, guardias, cámaras en cada sala, cerraduras en las vitrinas.
La seguridad no se puede agregar al final. Se incorpora en cada nivel: autenticación, autorización, cifrado, aislamiento, auditoría, mínimos privilegios. El arquitecto piensa en eso desde el primer día y se pregunta en cada decisión: «¿Y si un atacante consigue acceso acá?»
Un taxi para tres personas no debería andar como un tren bala. El tren bala no entra por un callejón.
«Hacelo rápido» es un requisito sin sentido. El arquitecto formula: cuántas requests por segundo, qué latencia es tolerable, cómo se comporta el sistema en el pico, qué pasa cuando se excede el límite. Optimizar antes de tiempo es desperdicio; no pensarlo en absoluto es una catástrofe.
La escalabilidad es la capacidad de crecer sin reescribir
Una casa pensada con la opción de sumar un segundo piso se amplía sin demolerla. Una casa sin esa opción — solo se cambia rehaciéndola desde cero.
El sistema tiene que crecer en dos direcciones: más usuarios (horizontalmente — sumamos servidores) y más funciones (modularmente — sumamos módulos sin romper los viejos). Eso se deja planteado en el diseño, no se agrega después.
La confiabilidad es cómo se comporta el sistema cuando algo se rompe
El buen barco no es el que no se hunde (esos no existen), sino el que tiene diez compartimentos y, si uno se rompe, los demás siguen flotando.
Cualquier parte del sistema, tarde o temprano, se va a romper. El arquitecto no intenta evitarlo — diseña cómo el sistema sobrevive a la falla. Aislamiento de fallas, reintentos, degradación elegante, fallbacks. La regla principal: la falla de un componente no debe matar todo el sistema.
Observabilidad — no se puede arreglar lo que no se ve
Un auto sin medidor de nafta, sin termómetro, sin indicador de presión de aceite. Anda hasta que se rompe del todo.
El sistema tiene que contar por sí mismo su propio estado: logs, métricas, traces. Cuando algo sale mal a las tres de la mañana, tenés minutos para encontrar el problema. Si la observabilidad no se planteó desde el inicio, agregarla después es tarde — ni siquiera sabés dónde mirar.
El sistema vive mucho tiempo. Lo van a cambiar. Una buena arquitectura es la que se cambia fácil.
Estar listo para el cambio importa más que ser correcto hoy
En una ciudad nueva, las calles se construyen más anchas de lo que hoy hace falta. Dentro de diez años hay más autos, y las calles angostas habría que romperlas.
El arquitecto no intenta anticipar todas las features futuras (es imposible). Deja la posibilidad de agregarlas sin romper lo que ya existe. Eso significa: boundaries claros, contratos extensibles, separar el «qué» del «cómo».
Mudarse de una casa vieja a una nueva es un proceso de meses. No podés tirar todo y comprar de nuevo.
Cuando un sistema tiene que cambiar (nueva base, nuevo protocolo, nuevo modelo de datos), eso no es «reescribir desde cero», es «llevarlo a través de una transición». Los sistemas reales funcionan durante los cambios. El arquitecto piensa el camino de migración desde el inicio; si no, la transición se vuelve imposible.
Borrar importa más que agregar
El placard no se puede ampliar para siempre. A veces hay que tirar lo viejo para que entre lo nuevo.
Todo sistema exitoso acumula con el tiempo código muerto, features sin uso, integraciones obsoletas. Es un impuesto que paga cada developer todos los días. El arquitecto plantea con regularidad la pregunta: «¿Qué podemos borrar?» — y a veces esa es la decisión arquitectónica más útil del año.
La mejor arquitectura es la que no hizo falta
La pared más fuerte es la que no hubo que tirar abajo, porque no se le metió nada de más por detrás.
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 partir el monolith «porque algún día». No construir un sistema de plugins «por las dudas». El buen arquitecto sabe cuándo decir «todavía no» o «esto no nos hace falta».
La arquitectura que nadie entiende no existe. La mitad del trabajo es transmitirla.
Una decisión arquitectónica se escribe, si no, se pierde
El testamento oral muere con su autor. El escrito sobrevive generaciones.
Cada decisión arquitectónica significativa hay que dejarla registrada: qué se eligió, qué alternativas había, por qué se descartaron, qué trade-offs se aceptaron. El documento no hace falta ahora — hace falta dentro de un año, cuando entre alguien nuevo y pregunte: «¿Por qué está hecho así de raro?» El formato estándar es un ADR (Architecture Decision Record).
Un diagrama vale más que mil palabras
Describir con palabras cómo llegar a una casa es largo y muchas veces inútil. Mostrar un mapa toma un segundo.
El arquitecto siempre tiene un diagrama del sistema: qué componentes hay, cómo se conectan, dónde están los boundaries. No perfecto — funcional. Sirve para explicar rápido a alguien nuevo y para que vos mismo veas el sistema completo. El modelo C4 (Context, Container, Component, Code) es simple y suficiente para la mayoría de los casos.
El arquitecto explica de manera que entienda alguien que no es ingeniero
El buen médico le explica el diagnóstico al paciente con palabras que el paciente entiende. El malo usa términos médicos después de los cuales el paciente asiente y no entiende nada.
Si el arquitecto solo puede explicar una decisión a otros ingenieros, se perdió la mitad del trabajo. Los stakeholders de negocio, producto, legales, seguridad — todos tienen que 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 dice que sí a todo pierde pacientes. El bueno se niega cuando la operación mataría.
El equipo pide a menudo decisiones que suenan razonables pero crean problemas de largo plazo. El arquitecto tiene que poder oponerse, explicar el riesgo y, a veces, sostener su posición — incluso cuando es impopular. Y también — reconocer cuando se equivoca, y cambiar la decisión cuando el contraargumento es más fuerte.
Checklists que el arquitecto se aplica antes de cualquier decisión y al final del día.
- ¿Qué problema se está resolviendo realmente? No la tarea como está planteada, sino el problema detrás. - ¿Qué alternativas hay? Al menos tres, incluyendo «no hacer nada». - ¿Qué pierdo con esta elección? Nombrar al menos dos desventajas. - ¿Qué tan reversible es esta decisión? Si es reversible, se decide rápido. Si no, hay que pensar más. - ¿Cómo se va a ver esto dentro de dos o tres años? No de manera ideal, sino realista. - ¿Quién, además de mí, tiene que entender esta decisión? Y cómo se la voy a explicar.
- ¿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 sobre cada hecho importante? Y dónde están sus copias — caches, réplicas, proyecciones. - ¿Qué boundaries entre componentes son explícitos y cuáles, accidentales? Los accidentales son deuda técnica. - ¿Qué pasa si se rompe cada dependencia externa? Una por una. - Si empezara de cero hoy, ¿qué haría distinto? Esa es la dirección de la evolución.
- Pasás más tiempo discutiendo y diseñando que escribiendo código. - Preguntás seguido «para qué», antes que «cómo». - Nombrás los trade-offs en voz alta, en vez de tratar de esconderlos. - Escribís documentos y diagramas más seguido que la mayoría. - Ves el sistema completo y podés explicar cualquiera de sus partes en contexto. - Pensás en las personas que van a trabajar con esto dentro de un año — y escribís de manera que les resulte cómodo. - A veces rechazás una tecnología hermosa porque no hace falta.
El arquitecto no es el que sabe más. Es el que piensa más tiempo antes de empezar a hacer.