I am Lino
2 de marzo de 2026

Fundamentos de arquitectura moderna (sin vender humo)

Publicado el 2 de marzo de 2026  •  15 minutos  • 3070 palabras
Table of contents

Imagina que alguien te dice: “he montado mi aplicación en un servidor on-premises con Oracle 9i, pero tranquilo, es arquitectura moderna porque lleva Docker”. Es en ese momento cuando entiendes por qué la gente abandona las reuniones de arquitectura fingiendo una urgencia dental.

Cuando hablamos de “arquitectura moderna” no hablamos de ponerle Kubernetes a cualquier cosa ni de ver cuántos palabros caben en una diapositiva. Hablamos de otra cosa mucho menos vistosa y mucho más difícil: construir sistemas que sobrevivan en el ecosistema actual sin quedarse obsoletos ni explotar cada vez que negocio cambia un requisito “tonto”. Sistemas que viven en la nube (o en varias), hablan por redes que fallan, guardan datos repartidos por medio planeta y tienen que seguir respondiendo cuando alguien decide que “ahora también tenemos que ser multi-región porque lo ha dicho un cliente importante”.

Este texto no es una receta mágica ni un panfleto de consultoría. Piensa más bien en una especie de manual de supervivencia: qué significa “moderna” en arquitectura, qué opciones reales tienes (monolito modular, microservicios, eventos, cloud-native…) y qué ideas deberías tatuarte en la frente antes de abrir tu siguiente diagrama en draw.io.

Qué puñetas significa “arquitectura moderna” (más allá de la sopa de siglas)

Lo primero es desmontar un mito: “moderna” no significa “microservicios por decreto” ni “si no usas Kubernetes eres legacy”. Significa, sobre todo, que aceptas el contexto en el que vives:

  1. Vas a desplegar en uno o varios clouds, públicos o híbridos, con reglas propias: instancias que aparecen y desaparecen, redes caprichosas, discos que no duran para siempre y facturas que crecen si te olvidas algo encendido.
  2. El usuario ya no está “al lado del servidor”: se conecta desde un móvil en otra región, con una latencia desesperante y un Wi-Fi sospechoso.
  3. Los requisitos de negocio se mueven rápido: lo que hoy es un MVP con un flujo simple, mañana tiene integraciones con tres proveedores, pagos en cinco monedas y un modo oscuro obligatorio “porque lo tienen todos”.
  4. Los datos han dejado de vivir en una sola base de datos central, ordenada y feliz: ahora tienes transaccional, cachés, almacenes analíticos, colas de eventos y, con suerte, algo de sentido común para unir todo eso.

Una arquitectura moderna, en este contexto, no se casa con un único estilo. Puede empezar como un monolito muy digno, volverse un monolito modular, sacar algunos microservicios para lo que realmente lo necesita, usar eventos donde la asincronía sea natural y apoyarse en principios tipo 12-Factor para no llorar cada vez que despliegas. No gana quien mete más cajas en el diagrama, sino quien consigue que el sistema siga siendo entendible dentro de cinco años.

El monolito clásico: de amor adolescente a bola de barro

Todo empieza inocente. Tienes una idea, montas un monolito: rutas, controladores, lógica de negocio, acceso a datos, scripts de batch, todo en un repositorio. Un único artefacto que subes a producción.

Para un equipo pequeño o un producto en sus primeros pasos, es casi perfecto: un solo pipeline, depuración fácil, latencias internas mínimas, y esa cálida sensación de que si ejecutas el proyecto en tu máquina, “está todo ahí”.

El problema no es el monolito, sino lo que solemos hacerle . Pasa el tiempo, las prisas aprietan, y cada módulo empieza a llamar a cualquier otro “porque total, está a mano”. La capa de negocio se mezcla con detalles de framework, las consultas SQL aparecen en sitios que daban miedo abrir, y para cambiar un pequeño comportamiento en facturación tienes que tocar tres capas, dos módulos y rezar a un santo patrón de tu elección.

Es lo que muchos artículos y charlas llaman, con ¿cariño?, la bola de barro arquitectónica : un sistema donde técnicamente “todo está conectado” y prácticamente nadie se atreve a tocar nada sin abrir primero una botella de antiácido, o de ácido clorhídrico en ciertos casos extremos.

El monolito modular: cuando el monolito va al gimnasio y madura

La versión adulta del monolito es el monolito modular . Por fuera, sigues desplegando una única aplicación; por dentro, has decidido que el caos tiene que pagar alquiler.

Empiezas a dibujar fronteras: dominios como Catálogo, Pedidos, Usuarios, Pagos dejan de ser carpetas aleatorias y se convierten en módulos con interfaces claras y dependencias controladas. Pedidos no puede llamar directamente a medio mundo, Usuarios no lee tablas que no son suyas solo porque sí, y los detalles de infraestructura (framework, ORM, drivers) se quedan en su capa, sin invadir la lógica de negocio.

Alguien podría decir: “pero eso suena a microservicios, ¿no?”. Y ahí está la gracia. El monolito modular te da muchas de las ventajas sin la complejidad operativa: no tienes latencia de red entre módulos, no necesitas observabilidad distribuida nivel NASA, y tu despliegue sigue siendo una sola unidad que puedes subir y bajar con relativa calma.

La diferencia clave es que, el día que de verdad tengas un problema que justifique sacar un módulo fuera (por ejemplo, si Pagos necesita escalar muy distinto, o tienes requisitos legales raros), puedes extraerlo con cirugía controlada, porque ya tenía fronteras internas. Para muchísimos sistemas, esto es más “moderno” que lanzarse de cabeza a 37 microservicios el primer día.

Microservicios: herramienta quirúrgica, no religión oficial

En algún momento del camino alguien leyó que las grandes empresas usan microservicios y decidió que, todo el mundo tenía que hacerlo. Esa historia suele acabar igual: con un sistema más complicado, más lento y más caro, pero con muchos diagramas muy chulos en las presentaciones internas.

En su versión seria, un sistema de microservicios divide capacidades en servicios pequeños, cada uno con su propio ciclo de vida, despliegue e, idealmente, su propia base de datos.

Esto tiene ventajas reales: puedes escalar solo lo que duele: si checkout sufre, escalas checkout, no todo el monolito; un fallo en el servicio de recomendaciones no debería tumbar la compra entera si pusiste bien los límites y aplicaste patrones de resiliencia; equipos distintos pueden trabajar y desplegar a ritmos diferentes sin pisarse constantemente, siempre que los contratos entre servicios estén claros.

Pero la factura existe : cada llamada entre servicios es una llamada de red que puede fallar, añadir latencia y necesitar tiempos de espera, reintentos, circuit breakers y todo el catálogo de patrones que suenan heroicos hasta que tienes que implementarlos. Los datos se reparten, aparecen problemas de consistencia y versiones de APIs que hay que soportar un tiempo. La operación del sistema (logs, métricas, trazas, despliegues, versionado) deja de ser “un poco liosa” y pasa a ser “necesitamos a alguien que solo se dedique a esto”.

La arquitectura moderna sensata no arranca por defecto en modo “microservicios a tope”. Suele empezar por algo más controlable (monolito modular) y solo cuando aparecen dolores reales (equipos demasiado grandes para un solo despliegue, necesidades de escalado muy distintas, límites organizativos claros) se extraen partes a servicios separados con un motivo concreto, no por deporte.

Vivir a base de eventos: “ha pasado esto, arréglate”

Hay otro giro que verás cada vez más: la arquitectura orientada a eventos . Aquí el centro de gravedad no son las llamadas directas, sino los hechos que van ocurriendo: “se ha creado un pedido”, “se ha confirmado un pago”, “el usuario ha subido un documento”, “el modelo ha hecho una predicción”.

El truco aquí es pensar en pasado: algo ha sucedido.

Por ejemplo, PedidoCreado es un mensaje lanzado al universo. El servicio de pedidos lo emite y, a partir de ahí, otros componentes se suscriben y reaccionan: uno manda un email, otro actualiza un panel, otro dispara un flujo de fraude, otro alimenta un almacén analítico. El emisor no sabe ni le importa quién está escuchando.

Esto tiene varias virtudes muy jugosas:

  1. Desacoplamiento real: el que emite no tiene que conocer a todos los consumidores.
  2. Extensibilidad sin dolor: puedes añadir nuevas reacciones (“ahora también queremos mandar un SMS”) sin tocar el servicio original.
  3. Escalado selectivo: si un evento se dispara mucho, escalas los consumidores que lo procesan, sin tocar todo lo demás.
  4. Log de negocio gratis: una secuencia de cosas que han pasado, útil para auditoría, depuración y modelos de ML que quieren entender cómo se comporta el sistema.

La letra pequeña: razonar sobre sistemas asíncronos es más complicado; hace falta buena observabilidad para seguir un evento desde que nace hasta que termina su viaje. Y te obliga a convivir con la famosa consistencia eventual: durante unos segundos, distintas partes del sistema pueden ver estados distintos de la realidad. Una arquitectura moderna no pretende negar eso, sino decidir con calma dónde se tolera (emails, métricas, recomendaciones) y dónde no (saldo de la cuenta, confirmación de un pago).

En la práctica, los sistemas interesantes acaban siendo híbridos: las interacciones críticas con el usuario suelen ser síncronas (“quiero saber ya si se ha cobrado mi compra”), y todo lo que puede ir en segundo plano viaja en eventos (“manda el recibo, actualiza el almacén de datos, recalcula el ranking de usuarios”).

Diseñar para la nube, no solo en la nube

Coger tu viejo monolito, empaquetarlo en una VM de AWS y proclamar que ahora es cloud-native es algo muy común… y bastante ingenuo.

Diseñar para la nube implica asumir unas cuantas cosas desde el principio: que las instancias van a morir y renacer como si nada, que el escalado horizontal (más instancias pequeñas) suele ser preferible a doblar la RAM de una sola, que la configuración cambia por entorno y no puede ir pegada al código, y que necesitas logs centralizados y métricas porque lo de hacer ssh y abrir /var/log/app.log a mano ya no escala.

El manifiesto de las 12-Factor Apps sigue siendo una especie de brújula: configuraciones en el entorno, dependencias explícitas, procesos sin estado, logs tratados como flujos hacia sistemas de agregación, separación clara entre construcción y ejecución, despliegues automatizados y repetibles, entornos de dev y prod razonablemente similares. No hace falta cumplir cada factor como si fuera un mandamiento, pero cuanto más los ignoras, más lloros futuros vas acumulando.

Hay unas preguntas sencillas que delatan si estás en el camino:

Si la mayoría de respuestas son razonables, estás más cerca de arquitectura moderna que mucha gente con Kubernetes en la firma de correo.

Latencia, estado y datos: los tres jefes finales

Más allá de los dibujitos, hay un puñado de temas transversales que conviene tener claros: cómo repartes responsabilidades, dónde pones los límites y cómo lidias con tres enemigos silenciosos — latencia, estado y datos.

Separación de responsabilidades: quién hace qué (y quién no)

Sigue siendo el principio más viejo y más pisoteado. Separar responsabilidades es evitar que el módulo de pagos sepa cómo se persisten usuarios en otra parte, que la lógica de negocio dependa de detalles de framework, o que el código que llama a un proveedor externo decida, además, si un pedido está pagado o no.

En un monolito modular se ve en forma de paquetes y módulos claros; en un sistema distribuido, en APIs que exponen acciones de negocio, no volcados de tablas con nombres en mayúsculas.

Límites claros: dónde acaba lo tuyo y empieza lo mío

Una arquitectura sana tiene fronteras que se pueden señalar: este módulo es de Facturación, aquel de Catálogo, este servicio es dueño de los “usuarios de negocio”, ese almacén de datos es solo para analítica.

Esas fronteras viven en contratos: tipos de mensajes, esquemas de eventos, endpoints, acuerdos de compatibilidad. Cuando están bien diseñados, cambiar algo dentro de un dominio no provoca un terremoto global; cuando no, cualquier columna nueva es un evento de nivel “todos a la sala de crisis”.

Latencia: la red siempre cobra peaje

En sistemas distribuidos, por muy optimizados que estén tus algoritmos, lo que manda es el tiempo que tarda todo en hablar con todo. Cada salto de red añade latencia y puntos de fallo. Si tu API llama a un servicio, que llama a otro, que consulta una base de datos en otra región… el usuario empieza a sospechar que su petición se ha ido a dar una vuelta turística.

Y luego está la física: entre Madrid y Virginia hay kilómetros, no hay magia. En multi-región y despliegues globales , cada decisión de “dónde vive qué dato” afecta directamente a la experiencia del usuario.

Arquitectura moderna aquí significa no diseñar como si todo fuera localhost: evitar cadenas síncronas profundas, usar cachés con cabeza, mover a asíncrono lo que no necesite respuesta inmediata y aceptar que algunas cosas simplemente van a tardar más.

Estado y datos: la parte pegajosa de todo esto

El estado es aquello que, si lo pierdes, alguien grita.

En un mundo cloud-native, la aplicación ideal es casi desechable: si un proceso muere, otro toma el relevo porque el estado importante vive fuera: bases de datos, cachés, colas, streams.

En cuanto repartes responsabilidades entre varios servicios, llegan las grandes preguntas:

No hay una única respuesta correcta, pero sí hay formas muy claras de equivocarse: la más habitual es inventarse microservicios, pero dejar un monolito de datos central al que todos leen y escriben alegremente. Has multiplicado la complejidad… sin ganar autonomía real.

Y ahora, ¿para qué me sirve toda esta película?

La idea de juntar todos estos fundamentos no es que puedas ganar discusiones en X con desconocidos, sino que tengas un pequeño marco mental al que volver cuando tomas decisiones concretas.

Si estás debatiendo si pasar de monolito a microservicios, no hables solo de “moda” o “escalabilidad infinita”: vuelve a lo de monolito modular, latencia, estado y equipos, y pregúntate qué problema real intentas resolver .

Si estás diseñando cosas de resiliencia como timeouts, circuit breakers o colas, encájalas dentro de tu visión de latencia y eventos, no como parches aleatorios.

Si negocio llega con multi-región y requisitos extraños de consistencia, revisa qué modelo de datos tienes y si puedes permitirte consistencia eventual en algún sitio sin que salten los abogados.

Al final, “arquitectura moderna” no va de ganar un concurso de diagramas bonitos. Va de responder, con un mínimo de seguridad y conocimiento, a tres preguntas:

Si consigues eso, da un poco igual si el dibujo final tiene un monolito modular muy digno, tres microservicios bien puestos y un puñado de eventos, o un zoológico entero en Kubernetes: lo que tendrás no será “lo último”, sino algo mejor… algo que funciona hoy y que tu yo futuro no querrá destruir mañana.

Glosario rápido

Traductor de jerga para que nadie se quede fuera de la conversación.

Fuentes y referencias

No te fíes solo de lo que dice un tío en Internet: aquí están las fuentes para que compruebes, discutas y, si hace falta, me corrijas.

Sígueme

Escribo y opino sobre tecnología, desarrollo de software y lo que se me pase por la cabeza.