Muchos sistemas distribuidos son problemas organizacionales disfrazados

Hay una pregunta que rara vez se hace al inicio de un proyecto de microservicios, y que debería ser la primera: ¿este sistema necesita ser distribuido, o nosotros necesitamos que lo sea?

No son lo mismo. Un sistema necesita ser distribuido cuando tiene requisitos reales que un único proceso no puede satisfacer: escala que excede una sola máquina, dominios con perfiles de disponibilidad incompatibles, componentes que deben evolucionar y desplegarse de forma genuinamente independiente. Una organización necesita que un sistema sea distribuido cuando tiene varios equipos que no logran coordinarse para trabajar sobre la misma base de código.

La segunda situación es mucho más común que la primera. Y produce sistemas distribuidos que resuelven un problema organizacional con herramientas técnicas — pagando el costo de la complejidad distribuida sin tener nunca el problema que esa complejidad existe para resolver.

La distribución como mecanismo de coordinación

Cuando varios equipos comparten un único despliegue, tienen que coordinarse. Comparten un pipeline, una ventana de release, un conjunto de pruebas de integración, una base de datos. Cada cambio de un equipo puede romper a otro. La coordinación es constante, y la coordinación es cara.

Llega un punto en que esa fricción se vuelve insoportable, y aparece una solución que parece técnica pero es organizacional: partamos esto en servicios, que cada equipo despliegue el suyo.

Y funciona. La fricción baja. Cada equipo recupera autonomía. Pero observa lo que acaba de pasar: la decisión de distribuir el sistema no vino de un requisito de escala, de latencia o de disponibilidad. Vino de la necesidad de que tres equipos dejaran de pisarse. El límite del servicio no se trazó donde estaba la frontera natural del dominio — se trazó donde estaba la frontera entre los equipos.

Esto es la Ley de Conway operando en su forma más pura. La arquitectura terminó siendo una copia de la estructura de comunicación de la organización. Solo que en lugar de reconocerlo, lo llamamos “arquitectura de microservicios” y lo justificamos con argumentos de escalabilidad que muchas veces nunca se materializan.

El síntoma: límites que no son de dominio

La señal más clara de que un sistema distribuido es un problema organizacional disfrazado es que sus fronteras no corresponden a fronteras del dominio, sino a fronteras de equipos.

En un sistema diseñado alrededor del dominio, los límites entre servicios coinciden con bounded contexts: lugares donde el modelo del negocio cambia de significado, donde las reglas son distintas, donde la consistencia puede relajarse de forma natural. Cruzar uno de esos límites es raro, y cuando ocurre, tiene sentido que sea una operación explícita entre contextos.

En un sistema diseñado alrededor del organigrama, los límites caen en lugares arbitrarios desde la perspectiva del dominio. Una sola operación de negocio cruza tres servicios porque cada paso lo posee un equipo distinto. Una transacción que conceptualmente es atómica se vuelve un baile de llamadas remotas, compensaciones y consistencia eventual — no porque el dominio lo exija, sino porque el flujo de trabajo atraviesa varios feudos organizacionales.

Límites por dominio (sano):
┌─────────────────┐   ┌─────────────────┐   ┌─────────────────┐
│    Pedidos      │   │    Pagos        │   │   Inventario    │
│  (un contexto   │   │  (un contexto   │   │  (un contexto   │
│   completo)     │   │   completo)     │   │   completo)     │
└─────────────────┘   └─────────────────┘   └─────────────────┘
  La mayoría de operaciones viven dentro de un solo servicio.

Límites por organigrama (problema disfrazado):
┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
│ Validar  │─▶│ Calcular │─▶│ Reservar │─▶│ Confirmar│
│ (Team A) │  │ (Team B) │  │ (Team C) │  │ (Team A) │
└──────────┘  └──────────┘  └──────────┘  └──────────┘
  Una sola operación de negocio cruza cuatro servicios
  porque cada paso pertenece a un equipo distinto.

Cuando la mayoría de tus operaciones de negocio cruzan múltiples servicios, no tienes un sistema distribuido bien diseñado. Tienes un monolito al que le pusieron latencia de red entre sus métodos.

El monolito distribuido: lo peor de ambos mundos

Ese resultado tiene nombre: monolito distribuido. Un sistema donde los servicios están físicamente separados pero lógicamente acoplados. No puedes desplegar uno sin desplegar otros. Un cambio en el contrato de un servicio obliga a cambios coordinados en varios. La supuesta independencia de despliegue es una ilusión, porque las dependencias siguen ahí — solo que ahora viajan por la red en lugar de por llamadas a funciones.

El monolito distribuido combina las desventajas de ambos mundos: la rigidez de coordinación del monolito y la complejidad operativa de lo distribuido. Tienes que lidiar con fallos parciales, latencia de red, serialización, observabilidad distribuida, consistencia eventual y debugging entre procesos — todo el impuesto de los sistemas distribuidos — sin obtener el beneficio principal, que es la independencia real.

Lo doloroso es que el monolito distribuido casi siempre nace de una buena intención organizacional mal canalizada: equipos que querían autonomía y la buscaron partiendo el sistema, sin alinear esa partición con las fronteras reales del dominio.

Por qué se disfraza de problema técnico

Si la raíz es organizacional, ¿por qué se presenta y se discute como un problema técnico? Por varias razones, y todas son entendibles.

Es más cómodo. Rediseñar la arquitectura es un proyecto técnico con tickets, sprints y entregables. Rediseñar cómo se comunican y se organizan los equipos toca política, egos, estructuras de poder y carreras. Lo segundo es mucho más difícil, así que la energía se va hacia lo primero.

Da una sensación de progreso. Migrar a microservicios se siente como avanzar. Hay diagramas nuevos, tecnología nueva, una narrativa de modernización. Decir “nuestro problema es que tres equipos no se coordinan bien” no se siente como progreso, aunque sea el diagnóstico correcto.

El vocabulario técnico está disponible y el organizacional no. Los ingenieros tienen un lenguaje rico para hablar de acoplamiento, cohesión, latencia y consistencia. Tienen mucho menos vocabulario compartido para hablar de fronteras de equipos, propiedad de dominios y costos de coordinación. Naturalmente, encuadran el problema en los términos que saben articular.

El resultado es que se invierte enormemente en resolver, con tecnología, un problema cuya causa raíz la tecnología no puede tocar. Y como la causa raíz sigue ahí, el problema reaparece en una forma nueva: ahora la fricción no está en el pipeline compartido, sino en los contratos entre servicios, en las reuniones de coordinación de APIs, en los equipos que se bloquean esperando cambios de otros.

La pregunta correcta antes de distribuir

Antes de partir un sistema, vale la pena separar deliberadamente las dos motivaciones, porque conducen a diseños distintos.

Si la motivación es técnica — escala que una máquina no soporta, dominios con disponibilidad incompatible, componentes con ciclos de vida genuinamente distintos — entonces los límites deben trazarse según esos requisitos técnicos y de dominio. La estructura de los equipos debería adaptarse a esa arquitectura, no al revés.

Si la motivación es organizacional — varios equipos que necesitan autonomía — entonces la pregunta no es “¿cómo partimos el sistema?” sino “¿cuáles son las verdaderas fronteras del dominio, y podemos alinear los equipos con ellas?”. Esta es la Maniobra Inversa de Conway aplicada con honestidad: en lugar de dejar que la estructura accidental de los equipos dicte la arquitectura, defines las fronteras de dominio correctas y organizas los equipos para que coincidan con ellas.

La diferencia es enorme. En el primer caso, distribuyes porque el problema lo exige. En el segundo, primero arreglas la organización y luego —quizás— descubres que necesitas menos distribución de la que creías, o que la distribución que necesitas cae en lugares completamente distintos.

A veces la conclusión honesta es que no necesitas microservicios en absoluto. Necesitas un monolito bien modularizado donde cada equipo es dueño claro de sus módulos, con fronteras internas fuertes y disciplina de dependencias. Eso te da gran parte de la autonomía que buscabas sin pagar el impuesto de lo distribuido.

Distribuir no arregla una organización rota

Hay una creencia implícita en muchas migraciones a microservicios: que la separación física va a imponer la disciplina que la organización no tiene. Que si ponemos una frontera de red entre los equipos, finalmente dejarán de acoplarse.

No funciona así. La distribución no crea fronteras organizacionales sanas — las hace más caras de cruzar. Si dos equipos no logran ponerse de acuerdo sobre una interfaz cuando comparten un repositorio, no van a ponerse mágicamente de acuerdo cuando esa interfaz sea un contrato de red versionado entre dos servicios desplegados por separado. El desacuerdo sigue ahí; ahora solo tiene más latencia y más superficie de fallo.

Los problemas de comunicación, de propiedad ambigua, de falta de alineación sobre el modelo del dominio — ninguno se resuelve con tecnología de distribución. Se trasladan. Y se vuelven más difíciles de ver, porque ahora se manifiestan como problemas técnicos de integración en lugar de como lo que realmente son: problemas de cómo trabajan juntas las personas.

Cierre

Los sistemas distribuidos son una herramienta poderosa para problemas reales de escala, disponibilidad y evolución independiente. Pero una porción significativa de las arquitecturas distribuidas que existen no nacieron de esos problemas. Nacieron de la fricción organizacional, y la distribución fue la forma técnica de no tener que resolver la causa real.

Antes de partir tu próximo sistema en servicios, haz la pregunta incómoda: ¿estoy resolviendo un problema del sistema, o estoy codificando la estructura de mi organización? Si es lo segundo, la solución más barata, más simple y más duradera casi nunca es más tecnología. Es alinear los equipos con las fronteras reales del dominio — y después decidir, con la cabeza fría, qué necesita distribuirse de verdad.

La arquitectura no reemplaza la comunicación organizacional. En el mejor de los casos la refleja; en el peor, intenta sustituirla con red y serialización, y termina cobrando el doble.