Del monolito a los microservicios: lecciones de 20 años

En 2004 desplegué mi primera aplicación Java en producción. Era un solo archivo WAR corriendo sobre Tomcat, respaldado por una base de datos Oracle. Veinte años después estoy construyendo microservicios orientados a eventos sobre Kubernetes que procesan millones de transacciones al día. El camino entre esos dos puntos me enseñó más sobre arquitectura de software que cualquier libro de texto.

Los años del monolito (2004–2012)

Al inicio de mi carrera, trabajando en empresas de Latinoamérica y Estados Unidos, cada aplicación era un monolito. ¿Y honestamente? Los monolitos son excelentes cuando empatan con tu equipo y tu escala.

Las ventajas que dábamos por sentadas:

• Despliegue simple — Un artefacto, un servidor, un procedimiento de rollback
• Depuración fácil — Los stack traces contaban toda la historia
• Integridad transaccional — Transacciones ACID a lo largo del dominio entero
• Baja latencia — Llamadas a métodos en proceso, no saltos de red

Los problemas se fueron colando poco a poco. Conforme crecieron los equipos, los conflictos de merge se volvieron batallas diarias. Un bug en el módulo de facturación tiraba toda la aplicación. Las ventanas de despliegue se extendían a los fines de semana porque nadie quería arriesgar un release en viernes. No podíamos escalar el servicio de catálogo —pesado en lecturas— sin escalar también el servicio de órdenes —pesado en escrituras.

El desvío de SOA (2012–2016)

La Arquitectura Orientada a Servicios prometía resolverlo todo. En la práctica introdujo nuevos problemas. Nuestros "servicios" eran en realidad un monolito distribuido conectado por un enterprise service bus (ESB) que se convirtió en un punto único de falla.

El ESB era un cementerio de transformaciones XML, reglas de ruteo y colas de mensajes que nadie entendía del todo. Cuando se caía —y se caía— todo se iba con él.

La lección: distribución no es descomposición. Partir un monolito a lo largo de fronteras de red sin replantear las fronteras del dominio solo te da lo peor de ambos mundos.

Microservicios bien hechos (2016–Presente)

Cuando me uní a equipos de ingeniería de mayor escala, abordamos los microservicios con más disciplina. Los principios que de verdad funcionaron:

1. Fronteras guiadas por el dominio

Cada servicio es dueño de un contexto acotado —una rebanada claramente definida del dominio del negocio. El servicio de cálculo de impuestos no sabe nada de autenticación de usuarios. El servicio de almacenamiento de documentos no sabe nada de reglas fiscales. Esto no se trata solo de organización del código; se trata de autonomía organizacional. Cada equipo puede desplegar de forma independiente.

2. Comunicación orientada a eventos

Pasamos de llamadas REST síncronas a una arquitectura orientada a eventos usando Apache Kafka. En lugar de que el Servicio A llame directamente al Servicio B, el Servicio A publica un evento ("DocumentUploaded") y el Servicio B reacciona a él.

// Producer
await kafka.produce({
  topic: "document.events",
  messages: [{
    key: documentId,
    value: JSON.stringify({
      type: "DocumentUploaded",
      payload: { documentId, userId, fileType },
      timestamp: Date.now(),
    }),
  }],
});

// Consumer
kafka.subscribe("document.events", async (event) => {
  if (event.type === "DocumentUploaded") {
    await extractionService.process(event.payload);
  }
});

Este desacoplamiento transformó nuestra confiabilidad. Cuando el servicio de extracción se cae, los eventos se acumulan en Kafka. Cuando se recupera, procesa el backlog. Cero datos perdidos, cero fallas en cascada.

3. La regla de una base de datos por servicio

Esta fue la píldora más difícil de tragar. Cada microservicio es dueño de su propio almacén de datos —sin bases de datos compartidas. El servicio de cálculo de impuestos tiene su propia instancia de PostgreSQL. El servicio de usuarios tiene la suya. Solo se comunican a través de APIs y eventos.

El trade-off es la consistencia eventual. No puedes hacer un JOIN de SQL entre servicios. Necesitas patrones tipo saga para transacciones distribuidas. Pero la independencia operativa que ganas vale la pena.

Los trade-offs que realmente importan

Después de dos décadas, esto es lo que me gustaría que alguien me hubiera dicho al principio:

• Los monolitos no son legacy — Si tu equipo es pequeño y tu dominio está bien entendido, un monolito se moverá más rápido que los microservicios. No distribuyas prematuramente.
• La red no es gratis — Cada llamada entre servicios añade latencia, modos de falla y complejidad de depuración. Mide el costo antes de partir.
• La observabilidad es obligatoria — En un sistema distribuido necesitas trazado distribuido (nosotros usamos OpenTelemetry), logging centralizado y métricas en tiempo real. Sin ellos vas volando a ciegas.
• La Ley de Conway es real — Tu arquitectura va a reflejar tu organigrama. Diseña primero tus equipos, después tus servicios.
• La automatización no es negociable — Si no puedes desplegar un servicio de forma independiente con un solo comando, no tienes microservicios —tienes un monolito distribuido.

Lo que sigue: arquitectura aumentada con IA

La siguiente evolución que estoy viendo son las decisiones de arquitectura aumentadas con IA. Estamos construyendo herramientas internas que analizan grafos de dependencias entre servicios, predicen cuellos de botella de escalamiento y recomiendan estrategias de descomposición basadas en patrones de tráfico. El rol del arquitecto está pasando de "diseñar el sistema" a "guiar la evolución del sistema".

A veinte años de carrera, estoy más entusiasmado con la arquitectura de software que nunca. Los fundamentos —cohesión, acoplamiento, separación de responsabilidades— no han cambiado. Pero las herramientas y patrones disponibles para implementarlos siguen mejorando.