El CTO mira el tablero de entregas y ve tres problemas a la vez: el monolito empieza a crujir, el inversor exige más velocidad y el equipo aún no tiene experiencia suficiente para operar una plataforma distribuida. Hay ocho ingenieros, dos candidatos en proceso y una decisión que parece urgente: ¿modular el sistema actual, dividirlo en microservicios o apostar por serverless?
La respuesta no sale de un diagrama de cajas. Depende del producto, de los atributos de calidad que importan, del presupuesto operativo y, sobre todo, de las personas que tendrán que mantener la solución. En España, donde el tejido del software está compuesto en un 99,8% por pymes y más del 85% son microempresas de menos de 10 empleados, según el diagnóstico sectorial citado en el informe sobre el estado del desarrollo de software en España, elegir una arquitectura que el equipo no puede operar es una forma rápida de fabricar deuda técnica.
La arquitectura de software exige conectar diseño, operación y contratación. Aquí encontrarás una comparación práctica de estilos, un método para registrar decisiones con ADRs, los trade-offs que aparecen al escalar y un checklist para evaluar talento técnico sin dejarte impresionar por el vocabulario de moda.
El día a día de quien decide la arquitectura
El CTO de una scaleup española recibe una petición aparentemente sencilla: duplicar la velocidad de entrega sin contratar un equipo de plataforma completo. El producto vive en un monolito Rails o Java, el despliegue se ha vuelto delicado y cada cambio toca más partes de las que debería. Mientras tanto, un inversor pide nuevas funcionalidades y dos candidatos prometen resolver el problema con enfoques opuestos.
El primer candidato propone microservicios. Habla de despliegues independientes, escalabilidad horizontal y equipos autónomos. El segundo recomienda un monolito modular, con límites de dominio claros, pruebas aisladas y un único proceso de despliegue. Ambos pueden tener razón. El error sería escoger por familiaridad tecnológica en lugar de preguntar qué restricción está bloqueando al negocio.
Un equipo pequeño no necesita más distribución. Necesita límites claros, ciclos de entrega predecibles y una operación que pueda entender durante una incidencia. Si todavía no existe una práctica sólida de automatización, observabilidad y despliegue, conviene revisar primero responsabilidades como las que cubre un perfil de ingeniero DevOps, antes de añadir más saltos de red y más puntos de fallo.
Regla práctica: no adoptes una arquitectura que requiera contratar varias especialidades antes de poder entregar valor con seguridad.
La decisión tampoco se toma en el vacío del organigrama. La arquitectura de software en España se apoya en un ecosistema de unas 532.200 personas ocupadas en programación, consultoría y actividades informáticas, según datos de la EPA del tercer trimestre de 2025 recogidos en el informe académico de la URJC citado por Experis. Existe talento, pero eso no significa que puedas contratar inmediatamente experiencia en sistemas distribuidos, seguridad cloud y fiabilidad.
Durante las siguientes decisiones, el CTO debe responder cuatro preguntas:
- Qué duele hoy: despliegues lentos, acoplamiento, latencia, fallos operativos o coste.
- Qué sabe operar el equipo: no solo qué frameworks conoce, sino cómo diagnostica y revierte cambios.
- Qué debe permanecer reversible: una decisión difícil de deshacer merece más evidencia.
- Qué resultado medirá el negocio: velocidad, disponibilidad, coste, calidad o una combinación explícita.
Qué es la arquitectura de software y qué decide un arquitecto
Los planos de un edificio no describen cada ladrillo. Definen cómo se distribuyen las cargas, por dónde pasan las instalaciones y cómo se puede reformar una zona sin derribar toda la construcción. La arquitectura de software cumple una función equivalente: establece la estructura que permite desarrollar, desplegar, proteger y modificar un sistema.
Un arquitecto no se limita a dibujar servicios. Decide dónde termina un módulo, qué datos controla cada componente y qué contrato permite que dos partes evolucionen sin romperse. También define cómo se despliega el sistema, cómo se detecta un fallo y qué compromisos acepta el negocio.
Las decisiones que afectan al producto
En la práctica, el arquitecto trabaja sobre varias dimensiones conectadas:
- Estructura: módulos, capas, dependencias y límites de dominio.
- Comunicación: llamadas síncronas para respuestas inmediatas, mensajería asíncrona cuando conviene desacoplar procesos.
- Persistencia: modelo relacional, documentos, cachés, colas y reglas de consistencia.
- Operación: despliegue, rollback, health checks, logs, métricas y trazas.
- Seguridad: identidad, autorización, gestión de secretos, aislamiento y auditoría.
- Calidad: disponibilidad, latencia, mantenibilidad y coste.
La modularidad y el ocultamiento de información tienen raíces históricas claras. En 1968, Edsger Dijkstra defendió establecer una estructura correcta antes de codificar, y en 1972, David Parnas formuló ideas fundacionales sobre modularidad y ocultamiento de información, según el resumen académico difundido por la URJC sobre la formación y evolución de la arquitectura de software.
Arquitectura no es documentación decorativa
Una decisión arquitectónica cambia el trabajo diario de los desarrolladores. Si eliges comunicación asíncrona, tendrás que gestionar reintentos, duplicados, orden de eventos y trazabilidad. Si eliges un servicio separado, tendrás que asumir una interfaz, una estrategia de despliegue y una forma de diagnosticar errores entre procesos.
La disciplina ya ocupa un lugar central en la formación técnica española. La asignatura Arquitectura del Software aparece como obligatoria de especialidad en Ingeniería del Software en la Universitat Politècnica de Catalunya, con teoría y laboratorio, según el documento académico de la URJC citado anteriormente. La señal es importante: la arquitectura no es un contenido accesorio que se añade cuando alguien asciende a arquitecto.
La pregunta correcta no es “¿qué diagrama representa mejor el sistema?”. Es “¿qué decisiones permiten que este equipo entregue cambios seguros bajo estas restricciones?”.
Estilos y patrones que verás en cualquier equipo
Los estilos arquitectónicos no compiten por una medalla. Resuelven problemas distintos y trasladan el coste a lugares diferentes. Esta comparación sirve para iniciar una conversación, no para sustituir el análisis del dominio.
Comparativa de estilos de arquitectura
| Estilo | Equipo mínimo | Escalabilidad | Latencia | Observabilidad | Coste a 12-18 meses |
|---|---|---|---|---|---|
| Monolito clásico | Equipo pequeño | Escala como una unidad | Baja dentro del proceso | Sencilla al principio | Bajo al inicio, puede crecer con el acoplamiento |
| Monolito modular | Equipo pequeño o mediano | Escala como aplicación, con límites internos | Baja dentro del proceso | Gestionable y centralizada | Generalmente equilibrado |
| Microservicios | Varios equipos con autonomía operativa | Escala por servicio | Añade variabilidad de red | Alta complejidad | Mayor coste de plataforma y operación |
| Event-driven | Equipo con experiencia en mensajería | Escala consumidores y flujos | Variable, depende del procesamiento | Exige correlación y trazabilidad | Puede crecer por infraestructura y operación |
| Serverless | Equipo con experiencia cloud | Muy útil para cargas variables | Depende del arranque y del proveedor | Requiere herramientas específicas | Eficiente en cargas intermitentes, menos predecible en cargas sostenidas |
| Edge functions | Equipo familiarizado con distribución | Acerca lógica al usuario | Puede reducir distancia al consumidor | Distribuida y más difícil de depurar | Depende del proveedor y del patrón de uso |
El monolito clásico sigue siendo una opción válida cuando el dominio aún cambia rápido y el equipo necesita moverse sin mantener una plataforma compleja. El problema aparece cuando todos los módulos comparten datos, dependencias y ciclos de despliegue sin límites que protejan el cambio.
El monolito modular suele ser mi recomendación por defecto para una scaleup que todavía trabaja con un equipo compacto. Puede tener varias capas o bibliotecas, pero se despliega como una única aplicación o proceso. La definición coincide con la explicación académica de la diferencia entre monolito y microservicios. Bien ejecutado, permite separar bounded contexts, imponer dependencias y preparar futuras extracciones sin pagar desde el primer día el coste de una red distribuida.
Los microservicios tienen sentido cuando la independencia de despliegue resuelve un dolor real y existen dos o más equipos capaces de operar sus servicios. Cada servicio debe poder desplegarse de forma independiente y la separación debe partir del dominio del negocio, no de capas técnicas, como señala la literatura universitaria sobre diseño y despliegue independiente de microservicios.
Event-driven encaja cuando los procesos tienen consumidores independientes, toleran asincronía o necesitan absorber trabajo sin bloquear la petición principal. No elimina la complejidad. La mueve hacia contratos de eventos, idempotencia, reintentos y consistencia.
Serverless brilla con cargas intermitentes y picos impredecibles. Yo no lo elegiría como respuesta automática para procesamiento sostenido, flujos con latencia estricta o equipos sin experiencia en límites del proveedor. Las edge functions pueden acercar lógica al usuario, pero hacen más difícil reproducir y depurar el comportamiento.
En España, la mayoría de scaleups estarán mejor servidas por un monolito modular bien diseñado que por una malla prematura de microservicios. La arquitectura aburrida gana cuando reduce la carga operativa y deja al equipo concentrarse en el producto.
Cómo tomar decisiones de arquitectura sin acumular deuda
Antes de tocar código, escribe qué debe mejorar. “Escalar” no basta. Puede significar aceptar más tráfico, reducir el tiempo de respuesta, aislar despliegues, limitar el coste cloud o evitar que una incidencia bloquee todo el producto.
El flujo que recomiendo
- Define el atributo de calidad prioritario. Elige entre rendimiento, disponibilidad, seguridad, mantenibilidad, coste o velocidad de entrega. Puedes tener varios, pero ordénalos.
- Expón las restricciones. Registra el tamaño y la experiencia del equipo, el stack heredado, el presupuesto, los requisitos regulatorios y el plazo.
- Compara opciones reales. Incluye mantener el diseño actual. Una alternativa que no se considera de forma explícita suele desaparecer por inercia.
- Elige tácticas verificables. Límites de módulos, colas, cachés, pruebas de contrato, despliegues progresivos o instrumentación no son adornos. Son mecanismos para proteger atributos concretos.
- Registra la decisión en un ADR. Guarda el documento junto al código, revisa sus consecuencias y enlázalo desde la documentación operativa.
Un ADR útil puede ser breve, pero no debe ser vago:
Contexto: el monolito tiene dominios mezclados y cada cambio requiere coordinar varias zonas del código.
Opciones: mantenerlo sin cambios, extraer microservicios o imponer módulos dentro de la aplicación.
Decisión: adoptar un monolito modular con límites de dominio, interfaces internas y pruebas de contrato entre módulos.
Consecuencias: conservamos un despliegue sencillo, reducimos el acoplamiento y dejamos preparada una extracción futura. Aceptamos que los módulos seguirán compartiendo proceso y parte de la capacidad de escalado.
La decisión solo vale si el equipo la usa. Versiona el ADR, enlázalo con las tareas de implementación y define qué evidencia justificaría revisarlo. Un documento olvidado en una carpeta no guía a nadie.
Este recurso audiovisual puede servir para alinear a producto e ingeniería sobre el proceso:
Evita tres trampas: decidir sin medir el problema, presentar una preferencia personal como requisito técnico y confundir una migración con una mejora automática. Si no puedes defender una decisión con un atributo de calidad, no es arquitectura, es opinión.
Trade-offs que duelen cuando el sistema escala
La distribución no es gratis. Cuando separas componentes, compras independencia potencial y pagas con red, operación, coordinación y más estados intermedios.
Latencia y acoplamiento temporal
En un monolito, una llamada interna evita un salto de red. En microservicios, una petición puede depender de varios servicios síncronos, cada uno con su propia variabilidad. Google Cloud explica que los entornos híbridos y multinube introducen retrasos relacionados con la conectividad y la distancia geográfica entre regiones o centros on-premise, como detalla su guía sobre patrones distribuidos híbridos y multinube.
La pregunta de diagnóstico es concreta: ¿qué interacciones necesitan respuesta inmediata y cuáles pueden procesarse después? Si no tienes esa respuesta, no repartas el dominio todavía. También conviene revisar si una API necesita REST, GraphQL u otra forma de composición, en lugar de multiplicar llamadas desde el cliente. La comparación entre REST y GraphQL ayuda a encuadrar ese contrato, pero no sustituye el análisis de los límites de dominio.
Observabilidad y fallos parciales
Un monolito puede empezar con logs centralizados y una visión relativamente directa del proceso. En microservicios necesitas correlacionar IDs de petición, recopilar logs estructurados, métricas y trazas distribuidas, y distinguir un error de negocio de un timeout entre servicios.
La Junta de Andalucía recomienda recoger trazas, logs y métricas en cada microservicio y centralizarlos en un colector de telemetría para exportarlos a sistemas de observabilidad, según su documentación académica y técnica sobre telemetría en arquitecturas de microservicios. La pregunta es: ¿puede el equipo reconstruir el recorrido de una petición fallida sin acceder manualmente a varias máquinas?
Deuda técnica y límites mal cortados
Un servicio demasiado pequeño puede convertirse en un componente “charlatán”, dependiente de muchas llamadas y con una base de datos difícil de separar. Un bounded context mal definido hace que la migración de datos sea más dolorosa que el problema original.
Antes de dividir, pregunta: ¿qué equipo será dueño del servicio, qué datos controla y qué contrato puede mantener sin coordinar cada cambio con el resto? Si no hay una respuesta clara, empieza por módulos internos y observa el comportamiento real.
Dos arquitecturas reales en startups y scaleups
No puedo presentar como hechos verificables casos concretos con métricas privadas, como una scaleup de Barcelona que supuestamente duplicó su velocidad de entrega o una fintech de Madrid que superó un volumen específico de transacciones. Esas cifras y atribuciones no están documentadas en las fuentes disponibles. Sí puedo convertir ambos patrones en escenarios de decisión útiles para un CTO.
El escenario del monolito modular
Una scaleup B2B con un equipo pequeño mantiene una aplicación Rails en un único despliegue. El equipo separa facturación, usuarios y catálogo en paquetes con dependencias controladas, añade pruebas por módulo y reserva las interfaces públicas para los límites que realmente necesitan estabilidad.
La señal para elegir este camino no es nostalgia tecnológica. Es que la mayoría de cambios siguen atravesando el mismo producto, los equipos aún comparten prioridades y el coste de operar servicios independientes no resolvería un cuello de botella concreto. El equipo debería validar la decisión con tiempo de entrega, frecuencia de rollback, incidencias por despliegue y facilidad para modificar cada módulo.
El error más peligroso sería llamar “modular” a una carpeta que no impone ninguna regla. Sin límites automatizados, el monolito solo acumula nombres nuevos.
El escenario de la fintech distribuida
Una fintech puede decidir extraer pagos cuando necesita aislar requisitos de seguridad, disponibilidad o despliegue. Un enfoque prudente consiste en mover primero ese flujo a un diseño orientado a eventos, usando una plataforma como Kafka si el equipo puede operarla, y mantener el resto del producto en el monolito mientras observa resultados.
Las señales deben ser operativas: fallos concentrados en un dominio, necesidad de desplegarlo con un ciclo diferente, propiedad clara de los datos y capacidad para atender incidencias. El error que casi siempre encarece el trimestre es migrar varios dominios a la vez, antes de demostrar que el primero tiene límites correctos.
La lección común es sencilla. La decisión correcta depende más del tamaño, la experiencia y la forma de colaboración del equipo que de la moda arquitectónica del momento.
