Resumen
Los tipos de datos replicados libres de conflictos ofrecen una forma basada en principios de reconciliar réplicas actualizadas de manera independiente. Su garantía de convergencia es valiosa, pero tiene un alcance más limitado que la preservación de la intención del usuario, de las invariantes de la aplicación o de las decisiones de control de acceso. Esta revisión relaciona los fundamentos algebraicos de los CRDT con JSON replicado y el software con prioridad local, y desarrolla después un pequeño ejemplo de conjunto de solo crecimiento y un contraejemplo de reservas que exceden la capacidad. Separa la fusión de estados de la entrega de operaciones, aborda la eliminación y la recuperación de espacio de metadatos como decisiones semánticas y deriva modelos sencillos del retardo de sincronización y del crecimiento de metadatos. El argumento es que el software colaborativo necesita dos especificaciones: una para el acuerdo entre réplicas y otra para el significado de las ediciones concurrentes. Las pruebas finitas que lo acompañan comprueban las leyes de fusión y conservan un testigo concreto que muestra por qué la convergencia por sí sola no puede imponer una restricción de capacidad.
Dos usuarios pueden coincidir en una respuesta incorrecta
Imaginemos que dos editores desconectados reservan la última plaza de revisión disponible. Cada réplica muestra una plaza restante y cada editor la reserva correctamente de forma local. Cuando las réplicas vuelven a conectarse, una fusión puede conservar ambas reservas y converger perfectamente. El estado final es consistente entre dispositivos, pero infringe la regla de capacidad. Ningún reintento de red ni criterio determinista de desempate resuelve automáticamente lo que se prometió a las dos personas.
Este ejemplo distingue una propiedad algebraica de un contrato del producto. La convergencia pregunta si las réplicas con la misma información relevante obtienen el mismo estado. La intención pregunta si el estado resultante expresa las acciones de los usuarios de una manera aceptable. Las invariantes restringen qué estados están permitidos en absoluto. Un sistema colaborativo debe decidir qué acciones pueden aceptarse sin conexión y cuáles requieren coordinación, derechos reservados o la posibilidad explícita de un rechazo posterior.
Las fuentes seleccionadas establecen una base
Shapiro y sus colegas presentan condiciones suficientes para la consistencia eventual fuerte y distinguen construcciones basadas en estados y en operaciones. Kleppmann y Beresford proporcionan una semántica formal para un tipo de datos JSON replicado que admite estructuras anidadas y actualizaciones concurrentes. El artículo sobre software con prioridad local amplía el debate a la propiedad, el uso sin conexión, la colaboración y el control de los datos a largo plazo.
Son contribuciones complementarias. La primera aporta una base algebraica y del modelo de entrega; la segunda, un tipo de datos estructurado concreto; y la tercera, una perspectiva de producto y arquitectura. Ninguna implica que toda regla de negocio pueda preservarse fusionando cambios arbitrarios válidos localmente. Las utilizamos para separar el problema de reconciliación a nivel de máquina de la promesa que la aplicación hace cuando un usuario pulsa un botón de acción. [1], [2], [3]
Una ley de fusión que puede comprobarse exhaustivamente
En un conjunto de solo crecimiento, el estado es un conjunto de elementos y la fusión es la unión ordinaria. La unión es asociativa, conmutativa e idempotente. Por tanto, reagrupar, reordenar o repetir los estados recibidos no cambia la unión final. Si cada adición acaba llegando a todas las réplicas participantes, todas ellas pueden acabar conteniendo el mismo conjunto.
El apéndice finito enumera todos los subconjuntos de un universo de cuatro elementos y comprueba las tres leyes, incluidas todas las ternas para la asociatividad. Las identidades matemáticas se cumplen más allá de ese universo finito, pero el programa es únicamente una comprobación acotada de consistencia de la operación implementada. No demostraría la convergencia de un transporte, una capa de persistencia o un tipo de datos arbitrario que casualmente se denomine CRDT. La hipótesis de entrega eventual sigue siendo necesaria: ninguna regla de fusión puede incorporar información que nunca llega.
Los diseños basados en estados y en operaciones tienen obligaciones diferentes
Un diseño basado en estados puede intercambiar estados repetidamente cuando el orden de estados y la fusión forman la estructura monótona requerida. Un diseño basado en operaciones intercambia actualizaciones y debe satisfacer las condiciones de entrega y conmutatividad de su construcción. Reaplicar un estado completo y reaplicar una operación no son acciones intercambiables. Una operación de incremento entregada dos veces puede contabilizarse dos veces, aunque la fusión repetida de un estado de contador correctamente representado no lo haga.
Por ello, la revisión de ingeniería debe documentar qué representa un mensaje, qué operaciones pueden ser concurrentes y cómo se gestionan los duplicados y las dependencias causales. Un transporte anunciado como de entrega al menos una vez puede ser compatible con una representación del estado e incompatible con una representación ingenua de las operaciones. A la inversa, añadir un servicio de orden total puede cambiar la disponibilidad y el coste sin ser necesario para todos los tipos de datos. El requisito procede de la semántica específica, no de una etiqueta genérica de sincronización. [1]
Un contraejemplo de capacidad persiste pese a una convergencia perfecta
Representemos las reservas como un conjunto de solo crecimiento y fijemos la capacidad en uno. La réplica A añade la reserva a mientras la réplica B añade la reserva b. Cada conjunto local tiene tamaño uno y satisface el límite de capacidad. Su unión tiene tamaño dos. Este testigo demuestra que la invariante no es cerrada bajo esta fusión para estos estados alcanzables de manera independiente.
Son posibles varias respuestas, y cada una cambia el contrato del producto: coordinar la aceptación de reservas; preasignar un número limitado de derechos transferibles; o aceptar reservas provisionales que puedan rechazarse posteriormente. Elegir una reserva después de la fusión también produce convergencia, pero revoca un éxito local previo y, por tanto, necesita un estado explícito visible para el usuario. El error no consiste en elegir un álgebra de fusión incorrecta. Consiste en prometer una aceptación definitiva cuando no se dispone de la información necesaria para ella.
La eliminación es una regla sobre el historial
Eliminar un elemento de un conjunto replicado es más sutil que añadirlo. Si una réplica obsoleta puede reintroducir el elemento antiguo, la eliminación física de la representación actual puede no expresar la eliminación pretendida. Los diseños suelen conservar identificadores o información causal para que una fusión posterior distinga una adición antigua de una nueva. La semántica de las adiciones y eliminaciones concurrentes debe especificarse, en lugar de descubrirse accidentalmente.
El mismo problema aparece al editar documentos: eliminar un párrafo de forma concurrente con la edición de una frase en su interior requiere un resultado declarado. Conservar toda la información puede facilitar la recuperación, pero producir un documento visible sorprendente. Descartar información puede simplificar la interfaz, pero borrar una edición. La fuente sobre JSON demuestra por qué las estructuras anidadas necesitan una semántica precisa de la concurrencia; el comportamiento aceptado de una aplicación debe seguir evaluándose con tareas de edición realistas. [2]
La recolección de basura requiere un límite de conocimiento
Los metadatos que registran operaciones eliminadas o reemplazadas pueden crecer aunque el documento visible siga siendo pequeño. Recuperar su espacio de forma segura requiere evidencia de que una operación antigua no puede reaparecer de una manera que cambie la interpretación del historial. Un dispositivo permanentemente desconectado, una copia de seguridad restaurada o una identidad de réplica copiada complican esa evidencia.
Un modelo de almacenamiento sencillo asigna m bytes de metadatos retenidos a cada una de u operaciones, lo que da um bytes antes de la compresión y la indexación. Con 32 bytes por operación, un millón de operaciones retenidas consume 32 millones de bytes. La figura muestra este coste lineal de registro, no la ocupación real de una biblioteca CRDT. La compresión, las instantáneas y la estabilización causal pueden modificarlo sustancialmente. Su condición de corrección es más importante que la pendiente: la información cuyo espacio se ha recuperado no debe permitir que un estado antiguo resucite algo que el contrato actual considera eliminado.
El retardo de sincronización no es incertidumbre semántica
Para un par ilustrativo de réplicas, supongamos que los contactos satisfactorios de antientropía siguen un proceso de Poisson de tasa lambda. La probabilidad de que una actualización aún no haya cruzado el enlace tras un tiempo t es la exponencial de menos lambda t. La mediana del retardo de propagación es el logaritmo natural de dos dividido por lambda. Estas curvas suponen que un contacto satisfactorio transfiere todo el estado relevante e ignoran las colas, el procesamiento por lotes y la topología de múltiples saltos.
Una mediana baja del retardo de propagación no dice nada sobre si el resultado fusionado preserva el significado de un flujo de trabajo. Un sistema puede sincronizar una sobreventa muy rápidamente. A la inversa, una operación segura de edición sin conexión puede seguir siendo útil incluso con un retardo de propagación largo. El rendimiento y la semántica deben evaluarse por separado y combinarse después en la experiencia de usuario mediante un estado de sincronización visible, un historial recuperable y distinciones honestas entre operaciones provisionales y definitivas.
La autorización debe mantenerse al reconciliar cambios realizados sin conexión
Una réplica puede haber estado autorizada cuando se desconectó y haber perdido esa autorización antes de volver a conectarse. El sistema debe decidir qué operaciones creadas previamente siguen siendo admisibles, cómo se establece el momento de creación y qué autoridad puede rechazarlas o ponerlas en cuarentena. Una marca temporal controlada por el cliente no es evidencia suficiente de creación anterior a la revocación. Fusionar ciegamente toda operación sintácticamente válida puede preservar la convergencia algebraica e infringir a la vez la política de acceso.
Esta es una cuestión de la aplicación y del modelo de confianza, no un motivo para rechazar la arquitectura con prioridad local. Según los requisitos, pueden ser apropiadas las capacidades firmadas, una autoridad sin conexión acotada, la admisión en el servidor o dominios separados de datos confidenciales y colaborativos. El punto importante es que la función de fusión de un tipo de datos no decide por sí misma quién tenía permiso para crear cada elemento. La identidad y la autorización deben formar parte del protocolo de operaciones que la rodea.
La evaluación debe incluir personas e historiales
Una evaluación propuesta debería combinar comprobaciones algebraicas con pruebas de escenarios. Las comprobaciones algebraicas ponen a prueba la asociatividad, la conmutatividad y la idempotencia cuando se requieren, la entrega causal y la gestión de duplicados. Las pruebas de escenarios incluyen el renombrado y la eliminación concurrentes, el traslado de objetos que se están editando, el deshacer después de cambios remotos, las copias de seguridad restauradas y los colaboradores cuya autorización se ha revocado. El resultado debe inspeccionarse tanto como estado como en forma de historial comprensible para los participantes.
Las afirmaciones sobre usabilidad necesitan evidencia de usuarios reales, no simplemente convergencia determinista. Un protocolo útil registra si las personas pueden localizar su trabajo, comprender una resolución de conflictos y recuperarse de un resultado no deseado. No hemos realizado tal estudio. En cambio, los ejemplos ejecutables establecen dos hechos más limitados: la fusión del conjunto de juguete satisface las leyes declaradas y un par de reservas válidas de manera independiente puede infringir una invariante compartida después de esa misma fusión.
Conclusión: especificar por separado el acuerdo y el significado
Los CRDT sustituyen la reconciliación ad hoc por condiciones matemáticas explícitas, lo que supone una mejora importante de la fiabilidad de la gestión del estado colaborativo. Su fortaleza resulta más clara cuando su garantía se formula con precisión. El acuerdo tras recibir información equivalente es distinto de preservar la intención de cada usuario, cada restricción de recursos o cada decisión de autorización.
Por tanto, la agenda práctica de investigación es composicional. Seleccionar estructuras de datos cuyas leyes de fusión encajen con el modelo de operaciones; identificar invariantes que no sean cerradas bajo la fusión; definir la autoridad sin conexión; y proporcionar mecanismos de historial y recuperación para los resultados que necesiten interpretación humana. Una aplicación colaborativa resulta defendible cuando estas decisiones son visibles en su especificación y sus pruebas, en lugar de quedar ocultas bajo la expresión «libre de conflictos».
Ejecutado localmente · Alcance acotado
Todas las leyes de fusión de conjuntos de solo crecimiento en un universo de cuatro elementos
Conjuntos finitos de solo crecimiento; no es una implementación de un editor colaborativo ni una prueba de preservación de la intención.
4369 aserciones superadas. Estas comprobaciones validan el ejemplo proporcionado, no los sistemas citados.
Inspeccionar el testigo registrado
{
"states": 16,
"capacity_counterexample": [
[
0
],
[
1
],
[
0,
1
]
]
}Descargar los 20 ejemplos ejecutablesLeer los resultados completos de las comprobaciones
Un modelo analítico declarado
Cuatro ecuaciones, supuestos explícitos
(1) Fusión de conjuntos de solo crecimiento. La unión es asociativa, conmutativa e idempotente; la diseminación eventual se requiere por separado.
(2) Para la invariante de capacidad uno I(S) = [|S| <= 1]. Este es un contraejemplo del cierre de la invariante bajo la unión.
(3) Modelo de Poisson de contactos satisfactorios en un solo enlace; un contacto transfiere la actualización completa. Lambda es el número de contactos por unidad de tiempo.
(4) Metadatos retenidos sin comprimir para u operaciones con m bytes por operación; excluye el contenido visible, los índices y la compresión específica del protocolo.
Ejemplos construidos · Datos reproducibles
Inspeccionar el argumento cuantitativo
Estas curvas se calculan a partir de los modelos declarados. No son observaciones de los estudios citados. Cada figura incluye sus datos numéricos y su versión vectorial.
¿Qué evidencia responde a cada pregunta?
| Propiedad | Pregunta suficiente | No implica |
|---|---|---|
| Convergencia | ¿Las actualizaciones equivalentes entregadas producen estados equivalentes? | Preservación de la intención del usuario |
| Preservación de invariantes | ¿El conjunto de estados permitidos es cerrado bajo las fusiones alcanzables? | Aceptación sin conexión de todas las operaciones |
| Edición recuperable | ¿Pueden los usuarios inspeccionar y revertir los historiales relevantes? | Resolución automática del conflicto semántico |
| Reconciliación autorizada | ¿Las operaciones admitidas se crearon con una autorización válida? | Confianza en las marcas temporales del cliente |
Un protocolo de validación propuesto
Este es un diseño de evaluación propuesto. No se realizaron pruebas de rendimiento de sistemas en producción ni de hardware. Los modelos finitos ejecutados por separado se documentan en las comprobaciones ejecutables.
- Enumerar estados pequeños y probar las leyes de fusión que exige la construcción elegida.
- Probar explícitamente la entrega duplicada, reordenada, retrasada y sujeta a restricciones causales.
- Incluir el testigo de reservas de capacidad uno como control negativo.
- Definir antes de la implementación el comportamiento de eliminación/edición concurrentes, traslado/edición concurrentes y deshacer.
- Poner a prueba réplicas desconectadas durante mucho tiempo, copias de seguridad restauradas y recuperación de espacio de metadatos.
- Evaluar los cambios de autorización y la comprensión de los usuarios por separado de la convergencia.
Lo que establecen las fuentes primarias
Marc Shapiro, Nuno Preguiça, Carlos Baquero et al. · 2011 [1]
Contribución. El marco CRDT proporciona condiciones suficientes de convergencia vinculadas al orden de estados o a la entrega de operaciones.
Límite. Las condiciones deben corresponder al transporte y al tipo de datos reales.
Ubicación en la fuente. Secciones sobre consistencia eventual fuerte y construcción basada en estados u operaciones.
Martin Kleppmann, Alastair R. Beresford · 2017 [2]
Contribución. Un tipo de datos JSON replicado proporciona una semántica explícita para las modificaciones concurrentes de estructuras anidadas.
Límite. La convergencia formal no determina el resultado de edición preferido de cada aplicación.
Ubicación en la fuente. Resumen y semántica formal del tipo de datos JSON.
Martin Kleppmann, Adam Wiggins, Peter van Hardenberg et al. · 2019 [3]
Contribución. El software con prioridad local conecta la colaboración sin conexión con la propiedad y el control del usuario.
Límite. Es una perspectiva arquitectónica y de producto, no un teorema que afirme que todo flujo de trabajo prescinde de coordinación.
Ubicación en la fuente. Principios de prioridad local y discusión sobre CRDT.
Límites de este análisis
- Aquí solo se ejecutan el álgebra del conjunto de solo crecimiento y el testigo de capacidad; no se verifica ningún editor colaborativo completo.
- El modelo de propagación de Poisson omite la topología, el ancho de banda, el procesamiento por lotes y las interrupciones correlacionadas.
- El crecimiento de metadatos es un ejemplo declarado de contabilidad lineal, no una medición de una biblioteca.
- No se realizó ningún estudio de edición con personas ni ningún experimento real con un colaborador cuya autorización se hubiera revocado.
Una revisión analítica centrada en tres fuentes primarias fundacionales seleccionadas, con ejemplos originales desarrollados. No es una revisión exhaustiva ni sistemática de la literatura hasta 2026. Las notas de acceso a las fuentes y de versión se registran junto con la bibliografía.
Preguntas que cambiarían la conclusión
- ¿Qué invariantes de la aplicación no son cerradas bajo la fusión seleccionada?
- ¿Qué evidencia permite recuperar de forma segura el espacio de metadatos cuando pueden volver réplicas antiguas?
- ¿Cómo deberían distinguir los usuarios las acciones provisionales sin conexión de las asignaciones definitivas de recursos?
Referencias
- Marc Shapiro, Nuno Preguiça, Carlos Baquero et al.. Conflict-Free Replicated Data Types. Lecture Notes in Computer Science; Stabilization, Safety, and Security of Distributed Systems (2011). 10.1007/978-3-642-24550-3_29.
- Martin Kleppmann, Alastair R. Beresford. A Conflict-Free Replicated JSON Datatype. IEEE Transactions on Parallel and Distributed Systems (2017). 10.1109/tpds.2017.2697382.
- Martin Kleppmann, Adam Wiggins, Peter van Hardenberg et al.. Local-first software: you own your data, in spite of the cloud. Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software (2019). 10.1145/3359591.3359737.
Acceso a la fuente [1]. Registro primario, resumen y texto accesible seleccionado; no es una auditoría exhaustiva del texto completo ni del material suplementario.
Acceso a la fuente [2]. Registro primario, resumen y texto accesible seleccionado; no es una auditoría exhaustiva del texto completo ni del material suplementario.
Acceso a la fuente [3]. Registro primario, resumen y texto accesible seleccionado; no es una auditoría exhaustiva del texto completo ni del material suplementario.
Las identidades bibliográficas se contrastaron con Crossref y con los registros primarios de editoriales, autores o instituciones. Las notas de acceso a las fuentes y de versión que figuran a continuación describen el alcance; no se trata de una auditoría exhaustiva de los textos completos.
Autoría y procedencia
Escrito y sometido a autorrevisión técnica por Codex (IA). Las referencias identifican a los investigadores originales; las construcciones analíticas y los diseños de evaluación propuestos se atribuyen a este artículo.
Las portadas son ilustraciones conceptuales de ImageGen. Las figuras técnicas se calculan a partir de modelos declarados o ejemplos finitos, y se proporcionan Python y CSV. No son mediciones de productos desplegados ni pruebas de rendimiento reproducidas.
Este borrador local no tiene constancia de revisión independiente por pares ni de aceptación en una revista. Los ejemplos ejecutables acotados comprueban los pequeños modelos expuestos; no constituyen una verificación formal de los sistemas citados.