Detecção e resolução de conflitos

1) O que considerar conflito

Um conflito é uma situação em que duas ou mais fontes de alteração reclamam estados incompatíveis de uma mesma entidade, recurso ou invariante.

Sintaxe: alterações cruzadas de um arquivo/chave (merge conflict em Git, patch-conflito em Kustomize).
Semântico: documento correto em esquema viola invariante empresarial (valor do débito ≠ crédito, limite ultrapassado).
Operação/tempo: corridas de gravação/leitura, eventos duplicados, divergência de causalidade.
Domínios: transações concorrentes sobre o recurso (venda dupla do bilhete, overbook do produto).

O desafio é descobrir o conflito o mais cedo possível, explicar sua causa e escolher com segurança uma das ações: auto, retraio, fusão, compensação, escalação.

2) Mecanismos de detecção

2. 1 Versionabilidade e comparação de estados

ETag/If-Match em REST, rowversion/xmin em DB - Identificação lost update.
3-way merge (base, ours, theirs) - realce as edições incompatíveis.
Checksum/Hash por campo/documento é uma comparação barata.

2. 2 Marcas temporárias e causais

Lamport clock: ordem total «aproximada do tempo».

2. 3 Invariantes e limitações

Os circuitos e validadores (JSON Schema/OpenAPI) são uma validade de sintaxe.
Invariantes: Singularidade, inabilidade, equilíbrio, regras LCA.
Verificações de integridade: índice FK/UNIQUE/EXCLUDE, partial constraits.
Assert de domínio em código/política (OPA/Kyverno/Conftest).

2. 4 Detecção em fluxos de eventos

Idempotency Key/Dedup Store (por exemplo, Redis/DB com TTL): remoção de dublagens.
Transactional/Excactly-once em streaming: ID transactional, produtora epoch, consumer-ofsets.
Sequence gap detation: omissões, repetição (n, n + 1, n + 1).

2. 5 Observabilidade e sinalização

Prometedores de erros/conflitos/retrações.

3) Estratégias de resolução

3. 1 Totalmente automático (seguro por definição)

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

Garantia de convergência sem coordenação; é importante escolher a semântica de perda/preservação.
Operações de comutação: aplicadas em qualquer ordem (encartes, apêndice de logs).
Idempotent handlers: repetição não muda o resultado (upsert por chave, put-if-absent).
«deep merge + policy» com ordem determinada.

3. 2 Semiautomáticos (com política)

3-way merge + regras de matrizes ('replace'append'uniqueBy (key) |patchBy (key)').
LWW (Last-Write-Wins): simples, mas risco de perda de correção de causa.
As prioridades de origem são «digitação interativa> config do arquivo> default».
Regras empresariais: «Se o limite for ultrapassado - confirmação parcial/compensação».

3. 3 Coordenações

OCC/MVCC (bloqueio otimista/multiplicidade): confecção de versões, retrai.
Bloqueios pessimistas: 'SELECT... FOR UPDATE ', looks distribuídos (Redlock/DB-lock/etcd).
Consenso (Raft/Paxos): um líder decide a ordem; os conflitos são menores, o preço é latência.

3. 4 Homem-em-circuito (HITL)

UI para merj/arbitragem manual (especialmente conteúdo, tarifas, diretórios).
Pré-teste de diff, explicação de política, botões: "aceitar ours/theirs'," combinar campos "," criar compensação ".

4) Patternos por camadas de arquitetura

4. 1 API/REST/gRPC

Optimistic concertency: 'If-Match: <etag>', 409/412 em conflito → o cliente retraita com um ETag recente.
Idempotency-Key em POST (pagamentos/pedidos).
Semânticos 409: informe a causa e as ações propostas.

4. 2 Armazéns de dados

RDBMS: MVCC (snapshot isolation), índices exclusivos, índices parciais.
KV/Doc stores: versões/revisões, compare-and-swap (CAS).
Replicação multiplaster: aplique o relógio de versão/CRDT ou «write to líder only» para entidades críticas.

4. 3 Filas/streaming

Exactly-once (praticamente «efetivamente uma vez»): produtor transacional + atômico write-to-sink.
Dedup no console: armazenamento dos últimos N id, lógica upsert/merge.
Outbox/Inbox Pattern: publicação concordada de eventos.

4. 4 Configurações e IaC

3-way merge em GitOps, policy-gates (OPA/Kyverno) antes da aplicação.
Kustomize/Helm: estratégias de merja definidas e proibição de «chaves desconhecidas».
Terraform: plano-diff como um sinal de conflito «drivt vs desired».

5) Algoritmos e exemplos

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 o recurso REST

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"}

O cliente repassa, aplica o delta ao estado atual e repete.

5. 3 Conflito 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 (esboço)

Os itens são adicionados com uma marca única e os itens removidos por uma marca específica.
O conflito «add vs remove» é resolvido com marcas de formatação: remove apenas as marcas de formatação add visíveis.

6) Política de resolução: como formalizar

1. Ordem de origem (priority chain).

2. Estratégias por tipos de dados: escalares/objetos/matrizes/mídia.

3. Modelo de causa: se você usa versões, Lamport, vector clocks.

4. Semântica de perdas: O que pode ser perdido na LWW, onde é preciso consenso.

5. Janelas de tempo: TTL para dedução, janelas de idempotação.

6. Escalação: quando a resolução automática é proibida, os requisitos são UI/approval.

7. Compensações: SAGA-estratégia «cancel/compensate» para o cruzamento de invariantes.

7) Métricas e SLO

A frequência dos tipos é o tipo de tipo.
confidts _ resulted _ auto _ ratio - proporção de permissões automáticas.
mean _ time _ to _ resolution - tempo médio até a resolução.
lost _ update _ invidents - incidentes de atualizações perdidas.
idempotency _ hit _ rate é a proporção de chaves Idempotency que funcionou.
divergence _ depth - profundidade da discrepância de réplicas (vetor de versões).

Exemplo SLO: «≥ 99% dos conflitos de sintaxe são resolvidos automaticamente por ≤ de 5 c, e semânticos por ≤ de 15 min com HITL».

8) Cenários práticos

8. 1 Pagamentos

Chave: Idempotency-Key, OCC no balanço, SAGA para os passos reversíveis.
Conflito: Duplo cancelamento → dedução + verificação da versão do balanço → compensação parcial.

8. 2 Inventários/bilhetes

Opções: bloqueio pessimista de slot/local; reserva otimista com TTL vencido; fila «compare-and-reserve».

8. 3 Conteúdo/diretórios

3-way merge + HITL: o editor seleciona o resultado; regras auto para campos «seguros» (marcas SEO que não afetam o preço).

8. 4 GitOps/Kubernetes

Render e validação antes da aplicação; reject on unknown keys; «-force» sem ciúmes.
Detecção Draft e policy-enfurcado retrocesso.

9) Anti-pattern

A LWW está em todo o lado: fácil ao custo de perda de causalidade.
Retraias ocultas sem idempotidade: Duplicados de avalanche.
Sem uma política de matrizes explícita, a perda de pontos de configuração é «silenciosa».
Mutex global acima das redes: SPOF e bloqueios de longa duração.
Compensações «cegas» sem auditoria de razões: conflitos repetidos.

10) Folha de cheque de implementação

• Defina os tipos de conflito no domínio e os invariantes.
• Selecione o mecanismo de versão (ETag/xmin/vector clock).
• Inclua a idempotação em POST/commands críticos.
• Defina a política de merj por tipo de dados (escalares/matrizes/objetos).
• Inclua validadores de esquema e verificações de domínio até a comitiva.
• Configure as métricas de conflitos e alarmos.
• Para entidades críticas, líder/consenso, ou CRDT.
• Execute o flow de HITL e UX (diff, comentários, auditoria de £).
• Documente o SLO e os procedimentos de compensação (SAGA).

11) FAQ

Q: Quando escolher o CRDT e quando escolher o consenso?
A: O CRDT é adequado quando o evolutivo consistency é permitido e a alta disponibilidade/gravação local é importante. O consenso é para dados com invariantes rígidos e ordem de transação rigorosa (balanços monetários, permissões de acesso).

A LWW é suficiente?
Para capas, métricas e índices secundários, muitas vezes sim. Para dados do usuário e dinheiro, quase sempre não.

Q: Como escolher a janela de dedução?
A: Direcione-se para o atraso máximo esperado para a reapresentação da rede + jitter, adicione um estoque de 3-5 x p99.

Q: É preciso sempre fazer uma HITL?
A: Não. HITL deixe para conflitos em disputa/valor; o resto automatize e logue.

12) Resultados

Detecção e resolução de conflitos eficazes são uma combinação de versões, marcas de causa, invariantes e políticas claras, complementadas por algoritmos adequados (CRDT/OT/OCC/MVCC/consenso) e observabilidade. Sistemas onde o conflito é uma situação «normal» permanecem acessíveis e previsíveis; os sistemas onde o conflito é «exceção» são quebrados no pior momento. Selecione o modelo, formalize as regras e mede o resultado.