En el ecosistema tecnológico actual, el escalado vertical de la infraestructura ha alcanzado sus límites físicos y económicos desde hace muchos años. Plataformas de alta concurrencia como Netflix, Uber o sistemas financieros globales ya no dependen de un único servidor centralizado; en su lugar, delegan su estado operativo a clusters distribuidos compuestos por cientos de nodos.
Esta descentralización introduce un desafío fundamental: ¿Cómo garantizamos la consistencia de los datos y la tolerancia a fallos cuando la red es inherentemente poco confiable? Si un nodo falla o la red sufre una partición, el sistema debe seguir operando sin corromper la información y sin mostrar estados inconsistentes a los usuarios.
En el libro «Patterns of Distributed Systems«, Unmesh Joshi aborda este dilema desarmando la complejidad de herramientas líderes en la industria como Apache Kafka y etcd. Joshi demuestra que, independientemente del nombre comercial del software, la persistencia distribuida se reduce a una coreografía coordinada de patrones estructurados alrededor de un único concepto: el Log Replicado.
El Log como elemento fundamental del Estado (Fuente de la Verdad)
Para comprender la interacción de los patrones, es importante redefinir el concepto de Log. En este contexto, no nos referimos a archivos de texto plano para auditoría o troubleshooting de errores.
El Log representa una estructura de datos append-only (solo se permite escribir al final; las entradas ya registradas nunca se modifican ni se eliminan), secuencial e inmutable, que registra comandos de transición de estado — es decir, operaciones relativas, no valores absolutos.
Por ejemplo, para una cuenta bancaria:
El estado actual (balance=120) no está almacenado en ninguna parte como un valor persistido de forma independiente: se obtiene reproduciendo (replaying) el log desde el inicio, aplicando cada comando secuencialmente sobre el estado anterior. Esto es exactamente lo que hace Kafka con sus topics cuando se usan como event log en arquitecturas de event sourcing.
El principio teórico que sostiene este enfoque es la Máquina de Estados Replicada (Replicated State Machine): si logramos que múltiples nodos independientes procesen exactamente la misma secuencia de comandos en el mismo orden exacto, todos los nodos convergerán de manera determinista en el mismo estado final. Los patrones analizados detallan precisamente cómo construir, sincronizar y proteger este Log a través de la red.
Patrones y Casos de Uso Reales
Patrón 1: Write-Ahead Log (WAL)
La persistencia local es el primer eslabón de la tolerancia a fallos. Cuando un nodo recibe una solicitud de escritura, el ciclo de vida del dato no inicia en las estructuras de memoria volátiles (RAM) ni en los índices complejos de la base de datos, ya que un corte de energía en ese instante causaría una pérdida irreversible de información.
¿Cómo funciona? El nodo escribe el comando crudo de forma secuencial directamente en el almacenamiento persistente (disco duro) en un archivo denominado Write-Ahead Log antes de retornar una confirmación o alterar su estado en memoria. Debido a que las escrituras secuenciales evitan el seek time (búsqueda física) del disco, la latencia de la operación es mínima. En caso de un reinicio abrupto por fallo eléctrico, el nodo ejecuta un proceso de recuperación leyendo el WAL desde su origen, reproduciendo secuencialmente cada instrucción para reconstruir el estado exacto previo a la falla.
Caso de Uso Real (PostgreSQL): PostgreSQL implementa este patrón de forma literal a través de su Write-Ahead Log, almacenado en el directorio pg_wal/. Antes de modificar cualquier página de datos en el buffer pool (memoria), el motor escribe un registro del cambio en el WAL y fuerza su sincronización a disco (fsync). Solo entonces la transacción se considera confirmada (commit) ante el cliente. Las páginas modificadas permanecen en memoria y se persisten al datafile real de forma diferida y asíncrona, mediante un proceso llamado checkpoint. Si el servidor sufre una caída antes de ese checkpoint, al reiniciar PostgreSQL detecta el punto del último checkpoint confirmado y reproduce (replay) las entradas del WAL posteriores a ese punto para reconstruir el estado exacto de las páginas en memoria. Una vez que un checkpoint se completa exitosamente, los segmentos de WAL anteriores a él ya no son necesarios para la recuperación y pueden reciclarse o eliminarse — a diferencia de Kafka, donde el log es el dato permanente, en PostgreSQL el WAL es un mecanismo de tránsito: protege temporalmente los cambios hasta que el estado «real» (las tablas) queda seguro en disco.
Patrón 2: Leader and Followers
Cuando el almacenamiento se distribuye en múltiples servidores a través de una red, permitir que todos los nodos acepten escrituras de forma simultánea genera conflictos de ordenamiento irreconciliables (por ejemplo, el Nodo A registra el evento X en la posición 1, mientras el Nodo B registra el evento Y en la misma posición).
¿Cómo funciona? El sistema centraliza la autoridad delegando a un único nodo el rol de Líder, mientras que los nodos restantes asumen el rol de Seguidores. El Líder es el único punto de entrada para las operaciones de mutación de datos; recibe la petición del cliente, determina su posición secuencial exacta en la línea de tiempo (el índice del Log) y propaga la instrucción de manera ordenada a los Seguidores. Sin embargo, el Líder no confirma la escritura al cliente de forma inmediata: antes debe coordinarse con los Seguidores para garantizar que el dato esté seguro incluso ante su propia caída (el mecanismo exacto de esta coordinación se detalla en el siguiente patrón, Quorum y Confirmación de Escrituras). Los Seguidores no aceptan escrituras de clientes directamente, pero participan activamente en el protocolo de consenso: confirman la persistencia de cada entrada en su propio disco y votan en el proceso de elección si el Líder deja de responder.
Caso de Uso Real (etcd / Kubernetes): etcd, el motor de consistencia de Kubernetes que mantiene el estado de todo el clúster, implementa el Raft Consensus Algorithm (raft.github.io) para elegir un Líder y coordinar la replicación consistente del log entre los nodos del clúster. Cualquier modificación en los pods o configuraciones del sistema es coordinada por este Líder para evitar colisiones de estado en los despliegues.
Patrón 3: Quorum y Confirmación de Escrituras
La existencia de un Líder mitiga el problema del ordenamiento, pero introduce un punto único de fallo si este se desconecta. Además, el Líder no puede dar por confirmado un dato de forma aislada, ya que si falla antes de transmitirlo por la red, el cambio se perdería.
¿Cómo funciona? Para declarar una escritura como «confirmada» (committed), el Líder debe replicar el registro del log a sus Seguidores y esperar a que una mayoría estricta (Quórum) del clúster le devuelva un acuse de recibo confirmando que el dato ya está seguro en sus respectivos WAL locales. Matemáticamente, el quórum se calcula como:
Donde N es el número total de nodos. Un clúster de 5 nodos requiere el consenso de al menos 3. Esta técnica evita el escenario catastrófico de Split-Brain, impidiendo que dos facciones aisladas del clúster tomen decisiones contradictorias simultáneamente — matemáticamente, dos particiones de red no pueden alcanzar quórum al mismo tiempo, porque no pueden existir dos mayorías estrictas simultáneas sobre el mismo conjunto de N nodos.
Caso de Uso Real (Apache Cassandra): Aunque Cassandra utiliza una arquitectura leaderless — a diferencia del modelo basado en Líder descrito arriba, no existe un nodo central que ordene y replique las escrituras — logra la misma garantía matemática de quórum de forma distribuida: el cliente escribe directamente a N réplicas en paralelo, y la operación se confirma cuando W de ellas (el quórum de escritura) responden con éxito. Al ejecutar una mutación con un nivel de consistencia de QUORUM, la base de datos asegura matemáticamente que una lectura posterior, siempre que también se ejecute con nivel QUORUM, obtendrá el dato más actualizado — la garantía se sostiene porque los conjuntos de réplicas de escritura y lectura necesariamente se solapan en al menos un nodo (R + W > N)
Patrón 4: High-Water Mark
Garantizar que los datos estén guardados en la mayoría de los nodos es el paso interno, pero resta resolver el problema de la visibilidad frente al cliente: ¿Cuándo es seguro permitir que un usuario lea un registro del log?
¿Cómo funciona? El High-Water Mark (HWM) es un puntero dinámico que mantiene el Líder para indicar el último índice del log que ha alcanzado un Quórum del clúster (incluyendo al propio Líder). Todo registro con un índice menor o igual al HWM se considera seguro, inmutable y es apto para ser expuesto a las consultas de los clientes. Los registros que se encuentran por encima del HWM representan escrituras en tránsito que aún no han alcanzado la mayoría; por ende, se mantienen ocultos para los clientes, previniendo lecturas sucias (dirty reads) en caso de que el Líder falle y deba ser reemplazado por un Seguidor que no alcanzó a recibir dichos cambios.
Caso de Uso Real (Apache Kafka): Kafka aplica este concepto de forma literal bajo el mismo nombre. Cada partición mantiene su propio High Watermark, calculado como el offset mínimo confirmado por todas las réplicas del In-Sync Replica Set (ISR). Los consumidores solo pueden leer mensajes hasta ese offset — los mensajes más recientes, aunque ya estén físicamente escritos en el disco del líder de la partición, permanecen invisibles hasta que el ISR completo los confirma. En Raft (y por lo tanto en etcd), el concepto equivalente se llama commit index, aunque el mecanismo de fondo es idéntico. (Nota: versiones modernas de Kafka refinan este mecanismo con el concepto de «leader epoch» para resolver casos límite de inconsistencia tras un cambio de líder — un detalle que puedes omitir si buscas mantener el documento a nivel introductorio.)
Interdependencia de los Patrones
Los patrones definidos no operan de manera aislada. La resiliencia del sistema depende de una jerarquía de responsabilidades bien establecida:
| Patrón | Responsabilidad | Dependencia | Componente |
| Write-Ahead Log | Garantizar durabilidad local ante reinicios inesperados. | Sistema de Archivos (OS) | Almacenamiento Local (Disco) |
| Leader and Followers | Establecer un ordenamiento lineal de eventos en la red. | Red / Algoritmo de Elección | Flujo de Datos Inbound |
| Majority Quorum | Validar la inmutabilidad de una decisión de forma colectiva. | Leader and Followers | Consenso del Clúster |
| High-Water Mark | Delimitar la visibilidad de datos limpios para el consumidor. | Majority Quorum | Capa de Lectura (Clientes) |
Conclusiones
El WAL garantiza que un nodo individual nunca pierda un dato ya aceptado; el patrón Leader-Follower impone un orden único sobre esas escrituras distribuidas; el Quórum decide cuándo esa réplica ordenada es lo suficientemente segura para sobrevivir a la caída de cualquier nodo, incluido el propio Líder; y el High-Water Mark traduce esa seguridad interna en una garantía visible para el cliente. Ningún patrón resuelve el problema de la consistencia distribuida por sí solo — cada patrón complementa al anterior.
Comprender esta cadena cambia la forma en que un ingeniero evalúa herramientas como Kafka, etcd o Cassandra: en lugar de comparar feature lists o benchmarks de marketing, puede preguntar directamente qué patrón implementa cada sistema, cómo lo implementa, y qué garantías concretas se pierden cuando se relaja una configuración — por ejemplo, leer con ONE en lugar de QUORUM en Cassandra, o desactivar fsync en un WAL. Esa es la diferencia real entre configurar un sistema distribuido por ensayo y error, y configurarlo entendiendo exactamente qué riesgo se está asumiendo con cada decisión.
Publicaciones que te pueden interesar:
10 conceptos de IA que todo ingeniero de software debería conocer este 2026