Planteamiento y roles aplicables
Un sistema de comentarios con replicación geográfica almacena un comentario principal y su respuesta en réplicas diferentes. Un usuario no debe ver la respuesta y luego perder el comentario principal, ni leer una versión más antigua tras una escritura exitosa. Explique la consistencia causal frente a la linealizabilidad y la consistencia eventual, diseñe garantías de sesión y muestre cómo verificar que la implementación no presente inversión causal.
Esta pregunta encaja en entrevistas de sistemas distribuidos, backend, infraestructura e ingeniería general. No requiere una base de datos en particular. Especifique el modelo de réplicas, el retraso de replicación y el hecho de que las solicitudes transportan un contexto causal que puede propagarse.
Qué está evaluando el entrevistador
Una respuesta sólida tiene cuatro niveles: definir happens-before y distinguir la fuerza de las consistencias; mapear read-your-writes, monotonic reads, monotonic writes y writes-follow-reads a un flujo de solicitudes; explicar cómo una réplica espera o redirige para satisfacer dependencias; y utilizar replicación retrasada, mensajes reordenados y failover para demostrar las propiedades. También debe señalar que la consistencia causal no crea un orden total para escrituras concurrentes; la resolución de conflictos sigue siendo responsabilidad de la aplicación.
Preguntas para clarificar antes de responder
El concepto de "causalmente relacionado" suele provenir de una escritura seguida de una lectura en una misma sesión de cliente, una escritura que leyó el resultado de otra escritura, o una relación explícita padre-hijo en el dominio. Las escrituras concurrentes sin una arista happens-before pueden aparecer en órdenes diferentes en distintas réplicas. No defina la consistencia causal como que todos los clientes vean un único orden idéntico.
Aclare cuatro límites: si el contexto cruza reintentos y colas asíncronas; si una réplica puede quedarse permanentemente atrás; qué tan obsoleta puede ser una lectura; y si los conflictos usan LWW, CRDT o una regla de dominio. Sin estos límites, la garantía prometida no puede verificarse.
Estructura de respuesta en 30 segundos
“La consistencia causal exige que las escrituras causalmente relacionadas se observen en el mismo orden causal, mientras que las escrituras concurrentes pueden aparecer en órdenes diferentes. Proporciona garantías visibles para el usuario más fuertes que la consistencia eventual, pero no es linealizabilidad ni la consistencia externa de Spanner; esos modelos más estrictos también requieren que los resultados se ajusten a un único orden en tiempo real.
Yo propagaría un vector de versiones o un token causal opaco desde el cliente. Cada escritura envía sus dependencias conocidas a una réplica y fusiona la versión confirmada de vuelta en el token. Una lectura se dirige únicamente a una réplica que haya satisfecho el token, o bien espera o redirige; si no puede satisfacer el contrato, devuelve un resultado explícitamente degradado. Inyectaría retrasos de replicación, reordenamiento de mensajes, reintentos y failover, para luego verificar que una respuesta nunca aparezca sin su comentario principal y que una sesión nunca pierda su propia escritura, midiendo al mismo tiempo la latencia de espera, el tamaño del contexto y la tasa de fallback.”
Análisis detallado paso a paso
Contexto de dependencias y diseño de garantías de sesión
Represente el contexto del cliente como un vector de versiones o un token causal opaco. Una réplica rastrea las versiones que ha aplicado y verifica las dependencias antes de atender una lectura:
context = client.context
write(key, value, context):
result = replica.write(key, value, dependency=context)
context = merge(context, result.version)
return result
read(key, context):
replica = chooseReplicaSatisfying(context)
result = replica.readAfter(context)
context = merge(context, result.context)
return resultRead-your-writes significa que una lectura posterior no es más antigua que la propia escritura de la sesión. Monotonic reads significa que una sesión nunca retrocede en el tiempo. Monotonic writes significa que las escrituras de una sesión se aplican en el orden en que se confirmaron. Writes-follow-reads significa que una escritura posterior transporta las dependencias observadas por una lectura anterior. Si a una réplica le falta una dependencia, puede esperar, redirigir a una réplica con un punto seguro más reciente o devolver un resultado obsoleto marcado como degradado cuando el producto lo permita explícitamente. Esta última opción ya no puede afirmar que mantiene la garantía original.
Escrituras concurrentes, fallos y compensaciones de rendimiento
La consistencia causal solo restringe el orden derivable. Si dos usuarios editan el mismo texto de forma concurrente, no elige un ganador para la aplicación. LWW puede perder una actualización; los CRDTs o las fusiones de dominio pueden preservar mejor la intención, a costa de metadatos y complejidad de implementación.
Un contexto más preciso puede aumentar la espera por dependencias y la latencia de cola, y los vectores de versiones pueden crecer. Enviar cada solicitud a un nodo primario simplifica la garantía, pero sacrifica la latencia regional y la disponibilidad. La replicación con consistencia eventual es más económica, pero no proporciona automáticamente read-your-writes ni monotonic reads. Si el negocio requiere que el orden de confirmación coincida con el orden en tiempo real, evalúe linealizabilidad o consistencia externa, aceptando una mayor coordinación.
Plan de verificación ejecutable
Construya una prueba con una cadena causal única: escriba el comentario principal, léalo, escriba la respuesta y lea desde réplicas en diferentes regiones. Inyecte retraso de replicación, una partición de red, mensajes reordenados y duplicados, reintentos del cliente y failover del primario. Registre el token causal, la versión observada y el ID de réplica para cada lectura.
Valide como mínimo que una solicitud que observa una respuesta también pueda observar a su padre; que una escritura exitosa no sea seguida por una lectura más antigua en la misma sesión; que las versiones de lectura de la sesión sean monótonas; y que las escrituras concurrentes puedan observarse en órdenes diferentes pero converjan eventualmente bajo la regla de conflicto declarada. Conserve la secuencia de eventos infractora más corta para poder distinguir entre un token perdido, una verificación de dependencias incorrecta y un límite de sincronización (watermark) obsoleto en la réplica.
Ejemplo de respuesta de alta calidad
“Definiría la arista de padre a respuesta como happens-before. La consistencia causal exige que cada réplica preserve esa arista, mientras que dos comentarios creados simultáneamente pueden aparecer en órdenes distintos. La linealizabilidad requiere además un único orden en tiempo real; la consistencia eventual solo promete convergencia después de que cesen las escrituras.
El cliente mantiene un vector de versiones o token causal y lo propaga a través de reintentos, tareas asíncronas y llamadas entre servicios. Una escritura envía el token como dependencia y fusiona su nueva versión tras completarse exitosamente. Una lectura elige una réplica que haya satisfecho el token, o bien espera o redirige. Esto implementa read-your-writes, monotonic reads, monotonic writes y writes-follow-reads, sujeto a una semántica explícita de espera y fallback.
No afirmaría que la consistencia causal resuelve conflictos concurrentes. El mismo campo aún necesita LWW, un CRDT o una fusión de dominio. Las pruebas retrasarían y reordenarían la replicación, duplicarían solicitudes y realizarían failover entre réplicas, comprobando que una respuesta nunca quede huérfana de su padre, que las versiones de la sesión nunca retrocedan y que la latencia de cola, el tamaño del contexto, las esperas y las tasas de fallback se mantengan dentro del presupuesto declarado.”
Errores comunes
- Llamar a la consistencia causal un orden total global → las escrituras concurrentes no tienen un orden requerido → separe happens-before de la concurrencia.
- Decir que “las réplicas eventualmente se sincronizan” → eso no ofrece ninguna garantía de sesión → describa tokens, verificaciones de dependencias y selección de réplicas.
- Asumir que read-your-writes es el comportamiento predeterminado de la base de datos → el enrutamiento entre réplicas puede devolver una versión más antigua → propague la versión de escritura y verifique el límite (watermark) de la réplica.
- Perder el contexto en una cola asíncrona → el trabajo de la respuesta pierde la dependencia del padre → transporte el token en los mensajes y metadatos de reintento.
- Afirmar que LWW resuelve conflictos causales → LWW puede sobrescribir una actualización concurrente → haga que la política de fusión sea una decisión independiente de la aplicación.
- Probar únicamente el camino exitoso → los retrasos, el reordenamiento y el failover exponen las inversiones causales → inyecte fallos y conserve la secuencia de eventos más corta.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Cuándo elegiría consistencia causal en lugar de linealizabilidad?
Elija linealizabilidad o una semántica más fuerte cuando cada cliente deba observar un único orden en tiempo real y las operaciones deban parecer atómicas en una sola máquina. La cronología de comentarios a menudo necesita visibilidad padre-hijo y garantías de sesión, por lo que la consistencia causal puede retener un mejor rendimiento de lecturas locales. Un saldo de pagos primero debe satisfacer su invariante de negocio antes de asumir el costo de coordinación.
Pregunta de seguimiento 2: ¿Puede una réplica devolver una lectura obsoleta cuando le falta una dependencia?
Solo si la API la etiqueta como degradada y el llamador acepta ese contrato. Si el producto promete que ver una respuesta implica ver a su padre, una lectura obsoleta viola el contrato; espere, redirija o devuelva un error reintentable e incluya el presupuesto de espera en el SLO.
Pregunta de seguimiento 3: ¿Pueden los vectores de versiones crecer sin límite?
Un mayor número de réplicas y clientes incrementa los metadatos. La compresión de tokens, los leases, los puntos de estabilidad causal o un conjunto acotado de participantes pueden controlar el costo, pero cada técnica debe demostrar que no elimina dependencias requeridas. Mida el tamaño del contexto y la sobrecarga de fusión bajo la rotación esperada de participantes.
Pregunta de seguimiento 4: ¿Cómo demuestra que las pruebas cubren una inversión causal real?
Registre el ID de escritura, el token de dependencias, el límite aplicado (watermark), la réplica y el resultado de lectura para cada evento, y luego construya el grafo happens-before. Reproduzca la cadena infractora más corta y asegúrese de que las rutas de pérdida de tokens, entrega duplicada, reordenamiento y failover reproduzcan el fallo o activen una aserción.