Detección y resolución de conflictos

1) Qué considerar un conflicto

Un conflicto es una situación en la que dos o más fuentes de cambio alegan estados incompatibles de la misma entidad, recurso o invariante.

Sintáctico: cambios intersectoriales de un solo archivo/clave (merge conflict en Git, colisiones de parches en Kustomize).
Semántica: el documento correcto según el esquema infringe el invariante comercial (importe adeudado ≠ crédito, límite superado).
Operativo/temporal: carreras de escritura/lectura, eventos duplicados, discrepancias causales.
Dominios: operaciones competidoras sobre un recurso (doble venta de entradas, overbook de mercancías).

La tarea: detectar el conflicto lo antes posible, explicar su causa y elegir con seguridad una de las acciones: recuperación de automóviles, retiro, fusión, compensación, escalada.

2) Mecanismos de detección

2. 1 Versionabilidad y comparación de estados

ETag/If-Match en NAT, rowversion/xmin en DB - identificar la actualización perdida.
3-way merge (base, ours, theirs) - resaltar ediciones incompatibles.
Checksum/Hash por campo/documento es una comparación barata.

2. 2 Marcas temporales y causales

Clock de Lamport: orden total «aproximado en el tiempo».

2. 3 Invariantes y limitaciones

Circuitos y validadores (JSON Schema/OpenAPI) es una validez sintáctica.
Invariantes: singularidad, no negatividad, equilibrio, reglas ACL.
Comprobaciones de integridad: FK/UNIQUE/EXCLUDE índices, construcciones parciales.
Assert's dominios en código/directivas (OPA/Kyverno/Conftest).

2. 4 Detección en flujos de eventos

Idempotency Key/Dedup Store (por ejemplo, Redis/DB con TTL): rechazo de tomas.
Transactional/Exactly-once en streaming: transactional id, producer epoch, consumer offsets.
Sequence gap detection: pases, repeticiones (n, n + 1, n + 1).

2. 5 Vigilancia y alarma

Prometrías de errores/conflictos/retraídas.

3) Estrategias de resolución

3. 1 Totalmente automático (seguro por definición)

CRDT (Conflict-free Replicated Data Types): G-Counter, PN-Counter, OR-Set, LWW-Register, Map/Graph CRDT.

Garantía de convergencia sin coordinación; la elección de la semántica de pérdida/conservación es importante.
Operaciones conmutativas: se aplican en cualquier orden (incrementos, apéndices de registro).
Idempotent handlers: la repetición no cambia el resultado (upsert por clave, put-if-absent).
Fusión optimista de estructuras: 'deep merge + policy' con orden determinista.

3. 2 Semiautomático (con política)

3-way merge + reglas de matriz ('replace' append 'uniqueBy (key) |patchBy (key)').
LWW (Last-Write-Wins): simple, pero el riesgo de perder la corrección causal.
Prioridades de origen: «Entrada en línea> configuración del archivo> defectos».
Reglas de negocio: «si se supera el límite - confirmación/compensación parcial».

3. 3 Coordinación

OCC/MVCC (bloqueo optimista/multivergencia): versión de conciliación, retray.
Bloqueos pesimistas: 'SELECT... FOR UPDATE ', locks distribuidos (Redlock/DB-lock/etcd).
Consenso (Raft/Paxos): un líder decide el orden; hay menos conflictos, el precio es latencia.

3. 4 personas en circuito (HITL)

IU para el merge/arbitraje manual (especialmente - contenido, tarifas, catálogos).
Avance del diff, explicación de la política, botones: "aceptar ours/theirs'," combinar campos "," crear compensación ".

4) Patrones por capas de arquitectura

4. 1 API/REST/gRPC

Optimistic concurrency: 'If-Match: <etag>', 409/412 en conflicto → el cliente retoma teniendo en cuenta el ETag fresco.
Idempotency-Key en POST (pagos/pedidos).
Semántica 409: informar la causa y las acciones propuestas.

4. 2 Almacenes de datos

RDBMS: MVCC (isolation snapshot), índices únicos, índices parciales.
Tiendas KV/Doc: versiones/revisiones (rev), comparar-y-swap (CAS).
Replicación Multimaster: aplique el reloj de versión/CRDT o «write to leader only» para entidades críticas.

4. 3 colas/streaming

Exactly-once (prácticamente - «efectivamente una vez»): productor transaccional + escritura atómica-a-sink.
Dedup en consumer: almacenar el último N id, lógica upsert/merge.
Outbox/Inbox patrón: publicación coherente de eventos.

4. 4 Configuraciones e IaC

3-way merge en GitOps, policy-gates (OPA/Kyverno) antes de la aplicación.
Kustomize/Helm: las estrategias deterministas del merge y la prohibición de las «claves desconocidas».
Terraform: plan-diff como señal de conflicto «drift vs desired».

5) Algoritmos y ejemplos

5. 1 3-way merge (simplificado)

text resolve(base, ours, theirs):
diff1 = delta(base, ours)
diff2 = delta(base, theirs)
if independent(diff1, diff2): return apply(base, diff1 ⊕ diff2)
if conflictsOnlyInArrays: return arrayPolicyMerge(...)
else:
return CONFLICT with hunks

5. 2 OCC para el recurso NAT

http
Client reads
GET /accounts/42 -> ETag: "v17", body: {balance: 100}

Trying to write off
PUT /accounts/42
If-Match: "v17"
{balance: 50}

If someone has managed before
HTTP/1. 1 412 Precondition Failed
{error: "version_mismatch", currentEtag: "v18"}

El cliente vuelve a leer, aplica el delta al estado actual y lo repite.

5. 3 Conflicto semántico (invariante)

pseudo on Debit(accountId, amount):
current = read(accountId)
if current. balance - amount < 0:
return REJECT ("insufficient _ funds") # write early detection (accountId, version = current. version+1, balance=current. balance - amount)

5. 4 CRDT: OR-Set (croquis)

Los elementos se agregan con tag único, la eliminación es por tag específico.
El conflicto «add vs remove» se resuelve gracias a las etiquetas: remove elimina únicamente las etiquetas add visibles.

6) Política de resolución: cómo formalizar

1. Orden de origen (priority chain).

2. Estrategias por tipo de datos: escalares/objetos/arreglos/multimedia.

3. Modelo causal: si usted utiliza las versiones, Lamport, vector clocks.

4. Semántica de pérdidas: lo que se puede perder con la LWW, donde se necesita consenso.

5. Ventanas temporales: TTL para deduplicación, ventanas de idempotencia.

6. Escalamiento: cuando la autorización automática está prohibida, los requisitos de UI/approval.

7. Compensaciones: SAGA-estrategias de «cancel/compensate» para repasar invariantes.

7) Métricas y SLO

conflicts_total{type} - frecuencia por tipo.
conflicts_resolved_auto_ratio - proporción de autorizaciones automáticas.
mean_time_to_resolution es el tiempo medio hasta la liquidación.
lost_update_incidents - incidentes de actualizaciones perdidas.
idempotency_hit_rate es la proporción de claves Idempotency activadas.
divergence_depth es la profundidad de la divergencia de las réplicas (vectores de versión).

Ejemplo de SLO: «≥ el 99% de los conflictos sintácticos se resuelven automáticamente en ≤ de 5 s, los semánticos se resuelven en ≤ de 15 min con HITL».

8) Escenarios prácticos

8. 1 Pagos

Clave: idempotencia (Idempotency-Key), OCC en balance, SAGA para pasos reversibles.
Conflicto: doble cargo → dedoop + revisión de la versión de balance → compensación parcial.

8. 2 Inventario/entradas

Opciones: bloqueo pesimista de ranura/asiento; armadura optimista con TTL caducada; cola «comparar-y-reservar».

8. 3 Contenido/catálogos

3-way merge + HITL: el editor selecciona el total; Reglas automáticas para campos «seguros» (marcas SEO que no afectan al precio).

8. 4 GitOps/Kubernetes

Renderizado y validación antes de la aplicación; reject on unknown keys; prohibición de «--force» sin rugir.
Drift-detección y policy-enforced retroceso.

9) Anti-patrones

LWW dondequiera: simplicidad por el coste de pérdidas de la causalidad.
Retratos ocultos sin idempotencia: duplicados en forma de avalancha.
Ausencia de una política de matrices explícita: pérdida «silenciosa» de puntos de configuración.
Mutex globales en la parte superior de las redes: SPOF y bloqueos prolongados.
Compensaciones «ciegas» sin auditoría de causa: conflictos repetidos.

10) Lista de verificación de implementación

• Identifique los tipos de conflictos en el dominio e invariantes.
• Seleccione el mecanismo de versionabilidad (ETag/xmin/vector clock).
• Incluya la idempotencia en POST/comandos críticos.
• Establezca la política de medición por tipo de datos (escalares/matrices/objetos).
• Habilite los validadores de esquema y las comprobaciones de dominio antes del commit.
• Personalice las métricas de conflicto y alerta.
• Para las entidades críticas - líder/consenso, o CRDT.
• Trabajar HITL-flow y UX (diff, comentarios, audit log).
• Documentar SLO y Procedimientos de Compensación (SAGA).

11) FAQ

P: ¿Cuándo elegir un CRDT y cuándo un consenso?
R: El CRDT es adecuado cuando la consistencia eventual es válida y la alta disponibilidad/registros locales son importantes. El consenso es para datos con invariantes rígidos y un estricto orden de operaciones (balances monetarios, derechos de acceso).

P: ¿Es suficiente LWW?
R: Para cachés, métricas e índices secundarios - a menudo sí. Para los datos del usuario y el dinero - casi siempre no.

P: ¿Cómo elegir una ventana de deduplicación?
R: Centre en el retraso máximo esperado de la reempresa + red jitter, agregue el stock 3-5 × p99.

P: ¿Es necesario hacer HITL siempre?
R: No. Dejar HITL para conflictos polémicos/de valor; automatizar y lógica el resto.

12) Resultados

La detección y resolución efectiva de conflictos es una combinación de versionalidad, marcas causales, invariantes y políticas claras, complementada con algoritmos adecuados (CRDT/OT/OCC/MVCC/consenso) y observabilidad. Los sistemas en los que el conflicto es una situación «normal» siguen siendo accesibles y previsibles; los sistemas donde el conflicto es una «excepción» se rompen en el momento más inapropiado. Seleccione un modelo, formalice las reglas y mida el resultado.