Desde fuera parece uno; por dentro nunca todo ocurre a la vez
La computación distribuida organiza varios ordenadores conectados para que colaboren en una tarea o servicio y se comporten, en lo posible, como un sistema coherente. Cada máquina tiene memoria y reloj propios, y los mensajes tardan, se pierden o llegan fuera de orden. Además, una parte puede fallar mientras las demás siguen activas. Esa combinación distingue un sistema distribuido de un programa paralelo dentro de un único ordenador y convierte la coordinación, no solo la potencia, en el problema central.
Una web global, una base de datos replicada o un cálculo científico pueden distribuirse por razones distintas: atender usuarios cercanos, procesar más datos, sobrevivir a fallos o compartir recursos. Añadir máquinas no garantiza mejora. La comunicación, la coordinación y el reparto desigual de carga introducen costes que pueden superar el trabajo útil.
No existe un reloj perfecto que ordene todos los hechos
En una sola máquina, el sistema operativo ofrece un orden relativamente claro. Entre centros distantes, los relojes se desajustan y la red varía. Si dos usuarios editan el mismo dato casi al mismo tiempo, una marca horaria local puede no revelar qué ocurrió antes. Los sistemas usan relojes lógicos, versiones o protocolos de consenso para construir el orden necesario sin fingir una simultaneidad absoluta.
La latencia no es solo lentitud: limita las decisiones. Esperar confirmación de muchas réplicas mejora certeza, pero aumenta tiempo de respuesta y puede bloquear el servicio durante una partición de red. Responder con menos confirmaciones mantiene disponibilidad y acepta que algunas lecturas sean temporalmente antiguas. El diseño escoge qué garantía necesita cada operación.
Copiar datos protege y complica a la vez
La replicación mantiene copias en varias máquinas para acercar información y resistir pérdidas. Si todas las escrituras pasan por un líder, ordenar resulta más sencillo, pero ese líder debe elegirse de nuevo si falla. Con varios escritores, el sistema necesita detectar y resolver conflictos. Una copia de seguridad no es lo mismo: la réplica participa en el servicio y puede propagar también un borrado erróneo.
Particionar divide el conjunto de datos entre nodos. Una clave puede decidir dónde vive cada registro, y técnicas de balanceo reparten cambios de carga. Las consultas que cruzan particiones cuestan más que las locales. Por eso el esquema de distribución debe seguir los accesos reales: fragmentar de manera uniforme no garantiza repartir de forma útil.
Acordar una decisión cuando alguien puede desaparecer
Protocolos como Raft permiten que un grupo acuerde una secuencia de operaciones pese a fallos de algunos nodos. Eligen líder, replican entradas y consideran comprometida una decisión cuando la confirma una mayoría. La mayoría hace que dos grupos capaces de decidir se solapen, evitando historias incompatibles bajo el modelo de fallos asumido.
Consenso no significa que todas las máquinas estén siempre de acuerdo ni que resista cualquier desastre. Si no hay mayoría comunicada, el sistema prioriza seguridad y deja de aceptar ciertas operaciones. También presupone tipos de fallo; tolerar nodos que se detienen es distinto de tolerar respuestas maliciosas. Los sistemas tolerantes a fallos deben declarar qué amenazas cubren.
«El dato correcto» puede depender del momento
La consistencia fuerte intenta que las operaciones parezcan ejecutarse en un único orden. La consistencia eventual permite que réplicas difieran durante un tiempo y converjan después si cesan las actualizaciones. Un saldo o un bloqueo puede requerir garantías fuertes; el contador aproximado de reacciones quizá tolere retraso. Elegir una garantía más débil sin explicarla produce sorpresas, pero exigir la máxima en todo desperdicia capacidad.
Durante una partición de red no se puede garantizar simultáneamente disponibilidad total y una única visión consistente para cada operación. Este principio no obliga a escoger una letra para todo el producto: distintas rutas pueden comportarse de manera diferente. Además, la latencia y los fallos existen incluso sin una partición perfecta. El diseño real combina garantías por operación, recuperación e idempotencia.
El reto continúa después de que el algoritmo funciona
La computación en la nube facilita obtener máquinas, pero no elimina fallos distribuidos. Se necesitan métricas, trazas que sigan una petición, límites de reintentos y despliegues graduales. Reintentar una compra sin una clave idempotente puede cobrar dos veces. Un fallo parcial obliga a distinguir «no se ejecutó» de «se ejecutó y la respuesta se perdió».
El dato memorable es que el problema más difícil no suele ser dividir un cálculo, sino saber qué ocurrió cuando la red calla. Sistemas como bases globales sacrifican simplicidad para ofrecer orden y disponibilidad medibles. Los centros de datos aportan infraestructura; la computación distribuida aporta protocolos para convivir con distancia e incertidumbre. Un sistema profesional diseña el fallo como estado normal, no como excepción imposible.
Una petición puede fallar lejos del lugar donde se nota
En un programa local, un error suele dejar una pila de llamadas en una máquina. En un sistema distribuido, la misma petición atraviesa servicios, colas y bases de datos con relojes diferentes. Registros, métricas y trazas distribuidas conectan esas etapas mediante identificadores. Sin esa observabilidad, una respuesta lenta puede confundirse con falta de CPU cuando en realidad espera una dependencia remota o reintenta una operación.
Observar tampoco equivale a guardar todo. El volumen puede ser enorme, contener datos sensibles y elevar costes. Se eligen señales vinculadas a objetivos de servicio, se muestrean trazas y se conservan eventos suficientes para reconstruir fallos. Las pruebas de carga y de recuperación revelan comportamientos que el tráfico normal no muestra. Un sistema distribuido es operable cuando el equipo puede detectar degradación, localizar causas y restaurar servicio antes de comprender cada detalle interno.
