Un sistema distribuido es un conjunto de ordenadores independientes que, desde el punto de vista del usuario, se comportan como un único sistema coherente. En el mundo actual, prácticamente cualquier aplicación de cierta envergadura (una banca online, una plataforma de comercio electrónico o un sistema de gestión de pólizas de seguros) es un sistema distribuido. Comprender sus fundamentos es imprescindible antes de abordar los microservicios, porque casi todos los problemas difíciles de las arquitecturas modernas nacen de la naturaleza distribuida del sistema, no de los microservicios en sí.

En esta lección estableceremos qué significa "distribuido", desmontaremos las famosas falacias de la computación distribuida y analizaremos los tres grandes retos que todo arquitecto debe interiorizar: la latencia, los fallos parciales y la consistencia.

1. Qué es un sistema distribuido
2. Por qué distribuimos: ventajas y motivaciones
3. Las ocho falacias de la computación distribuida
4. Reto 1: la latencia de la red
5. Reto 2: los fallos parciales
6. Reto 3: la consistencia de los datos
7. Modelos de comunicación
8. Errores comunes y consejos
9. Ejercicios
10. Conclusión

Una definición clásica, atribuida a Andrew Tanenbaum, dice:

Un sistema distribuido es una colección de ordenadores independientes que aparecen ante sus usuarios como un único sistema coherente.

Las tres ideas clave son:

• Independientes: cada nodo tiene su propia memoria, su propio reloj y puede fallar por separado.
• Coordinados: los nodos cooperan intercambiando mensajes a través de una red.
• Transparencia: idealmente, el usuario no percibe que hay varias máquinas.

Una característica fundamental, formulada por Leslie Lamport, lo resume con ironía:

Un sistema distribuido es aquel en el que el fallo de un ordenador del que ni siquiera sabías que existía puede dejar inutilizable tu propio ordenador.

En este diagrama, cada nodo (gateway, servicios, bases de datos) es un proceso independiente que se comunica por red. Las flechas continuas representan llamadas directas y la flecha discontinua una comunicación asíncrona entre servicios.

Distribuir un sistema añade complejidad, así que solo merece la pena cuando obtenemos beneficios reales:

La regla de oro: no distribuyas por moda. Distribuye cuando un único servidor ya no basta o cuando la organización necesita autonomía entre equipos.

En 1994, Peter Deutsch y otros ingenieros de Sun Microsystems enumeraron las suposiciones erróneas que los desarrolladores hacen repetidamente al construir sistemas distribuidos. Cada una de ellas es falsa, y olvidarlo provoca bugs sutiles y caídas en producción.

El siguiente ejemplo en Java muestra código que cae en la falacia 1 y 2 (la red es fiable y la latencia es cero):

Aquí no hay timeout, ni reintentos, ni manejo de error. Si el servicio remoto tarda o falla, el hilo se queda colgado. La versión correcta exige timeouts explícitos y gestión de fallos, algo que veremos en la lección de resiliencia.

La latencia es el tiempo que tarda un mensaje en viajar de un nodo a otro. A diferencia de una llamada a un método local (nanosegundos), una llamada por red cuesta órdenes de magnitud más. Una referencia mental útil (números aproximados de Jeff Dean):

La consecuencia práctica es que hacer muchas llamadas pequeñas por red es muy caro. Este antipatrón se conoce como "N+1 de red":

Si hay 100 pedidos, esto son 101 llamadas de red. La solución es agrupar (batching), pidiendo todos los clientes de una vez:

Reducimos de 101 a 2 llamadas: la diferencia de rendimiento es enorme.

En un sistema monolítico, o todo funciona o todo falla. En uno distribuido aparece un estado nuevo y peligroso: el fallo parcial, en el que unos componentes funcionan y otros no.

El caso más difícil es la incertidumbre: cuando enviamos una petición y no recibimos respuesta, no sabemos si:

• la petición no llegó al destino,
• llegó y se procesó pero la respuesta se perdió,
• el destino sigue procesándola lentamente.

Esto obliga a diseñar operaciones idempotentes: una operación es idempotente si ejecutarla varias veces produce el mismo resultado que ejecutarla una sola vez. Así un reintento es seguro.

La idempotencyKey (un identificador único que el cliente genera y reenvía en cada reintento) permite detectar duplicados. Sin ella, un reintento podría cobrar dos veces.

Cuando los datos están replicados o repartidos entre nodos, mantenerlos coherentes es difícil. Distinguimos dos modelos básicos:

La consistencia fuerte es cómoda para el programador pero cara en rendimiento y disponibilidad. La consistencia eventual escala mejor pero obliga a tolerar datos temporalmente desactualizados. En la lección sobre el Teorema CAP profundizaremos en por qué no se puede tener todo a la vez.

Existen dos grandes formas de comunicar nodos, que estudiaremos en detalle más adelante:

• Síncrona (petición/respuesta): el llamante espera la respuesta (REST, gRPC). Sencilla pero acopla disponibilidad: si B está caído, A se ve afectado.
• Asíncrona (mensajería/eventos): el llamante publica un mensaje y continúa (colas, eventos). Desacopla, pero introduce complejidad y consistencia eventual.

Este evento describe un hecho ocurrido ("una póliza fue creada"). Otros servicios pueden suscribirse y reaccionar sin que el emisor sepa quiénes son, lo que reduce el acoplamiento.

• Tratar las llamadas de red como llamadas locales: siempre habrá fallos y latencia. Pon timeouts en todas las llamadas remotas.
• Olvidar la idempotencia: si vas a reintentar, asegúrate de que la operación sea segura de repetir.
• Distribuir prematuramente: un monolito bien hecho suele ser mejor punto de partida que diez microservicios mal definidos.
• Ignorar la observabilidad: sin logs correlacionados, métricas y trazas, depurar un sistema distribuido es casi imposible. Usa un identificador de correlación que viaje en todas las peticiones.
• Confiar en los relojes: los relojes de distintas máquinas no están perfectamente sincronizados; no uses marcas de tiempo para ordenar eventos críticos sin un mecanismo adecuado.

1. Enumera las ocho falacias de la computación distribuida e indica, para cada una, una consecuencia práctica si la ignoras en el diseño.
2. Tienes un servicio de pagos que recibe peticiones por red. Explica por qué un simple reintento puede provocar un cobro doble y diseña, en pseudocódigo Java, una solución idempotente.
3. Estima cuántas veces más lenta es una llamada entre continentes (150 ms) frente a un acceso a memoria RAM (100 ns). Razona qué implicación tiene esto para el diseño de APIs.

1. Por ejemplo: La red es fiable → si no manejas errores, una conexión cortada deja la operación en estado inconsistente. La latencia es cero → si diseñas APIs "charlatanas" con muchas idas y vueltas, el rendimiento se degrada. (El resto se completa de forma análoga con la tabla de la sección 3.)

2. Un reintento provoca cobro doble porque, si la primera petición sí se procesó pero su respuesta se perdió, el cliente cree que falló y reenvía. Solución:

La clave es registrar la clave de idempotencia de forma atómica junto con el cobro.

3. 150 ms = 150.000.000 ns; 150.000.000 / 100 = 1.500.000 veces más lenta. Implicación: hay que minimizar el número de llamadas remotas (batching, cachés, agregación de datos) en lugar de diseñar APIs que requieran muchas idas y vueltas.

Hemos visto que un sistema distribuido es un conjunto de nodos independientes que cooperan por red y que parecen uno solo. Las ocho falacias nos recuerdan que la red no es fiable, ni instantánea, ni segura, ni gratuita. Los tres grandes retos (latencia, fallos parciales y consistencia) condicionan todas las decisiones de arquitectura que tomaremos a partir de ahora.

Con estos fundamentos claros, en la siguiente lección, Arquitectura de Microservicios, veremos cómo un estilo arquitectónico concreto aprovecha (y a la vez sufre) la naturaleza distribuida para construir sistemas escalables y mantenibles.