Rilevamento e risoluzione dei conflitti

1) Cosa considerare conflitto

Un conflitto è una situazione in cui due o più fonti di modifica richiedono stati incompatibili della stessa entità, risorsa o invariante.

Sintassi: modifiche intersecanti a un singolo file/chiave (merge conflict in Git, collisioni patch in Kustomize).
Semantico: il documento corretto in base allo schema viola l'invariante aziendale (l'importo del debito corrisponde al prestito, il limite è stato superato).
Operativi/temporali: corse di scrittura/lettura, eventi duplicati, differenze causali.
Domini: transazioni concorrenti sulla risorsa (doppia vendita del biglietto, overbook della merce).

L'obiettivo è individuare il conflitto il prima possibile, spiegarne la causa e scegliere in modo sicuro una delle azioni: auto, retro, fusione, compensazione, escalation.

2) Meccanismi di rilevamento

2. 1 Versionalità e confronto degli stati

ETAG/If-Match in REST. rowversion/xmin in DB - Rilevamento lost update.
3-way merge - Evidenzia modifiche incompatibili.
Checksum/Hash per campo/documento è un confronto economico.

2. 2 Etichette temporali e causali

Lamport clock - Ordine totale «più vicino al tempo».

2. 3 Invarianti e vincoli

Schemi e validatori (JSON) - validità sintassica.
Gli invarianti sono unici, ineleggibili, bilanciati, regole ACL.
Controlli di integrità: indici FK/UNIQUE/EXCLUDE, partial constrains.
I domini assert'in codice/regole (OPA/Kyverno/Conftest).

2. 4 Rilevamento nei flussi di eventi

Idempotency Key/Dedup Store (ad esempio Redis/DB con TTL) - taglia le riprese.
Transactional/Exactly-once in streaming: transactional id, producer epoch, console-offset.
Sequence gap detection: omissioni, ripetizioni (n, n + 1, n + 1).

2. 5 Osservabilità e allarme

Protettrici di errori/conflitti/retrai.

3) Strategie di risoluzione

3. 1 Completamente automatico (sicuro per definizione)

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

Garanzia di convergenza senza coordinamento; è importante selezionare una semantica di perdita/salvataggio.
Operazioni di commutazione: applicate in qualsiasi ordine (incarnazioni, loga-appendici).
Idempotent handlers - La ripetizione non cambia il risultato (upsert per chiave, put-if-assent).
La fusione ottimistica tra le strutture deep merge + policy e l'ordine definito.

3. 2 Semiautomatici (con criterio)

3-way merge + regole di serie ('replace'append'uniqueBy (key) |patchBy (key)').
LWW (Last-Write-Wins) - Semplice ma a rischio di perdita della correttezza causale.
Le priorità di origine sono input interattivo> config da file> default.
Regole aziendali: «Se il limite è superato, conferma/risarcimento parziale».

3. 3 Coordinatori

OCC/MVCC (Ottimist Block/Multiple) - Verifica delle versioni, Retrai.
Blocchi pessimistici: 'SELECT... FOR UPDATE ', lock distribuiti (Redlock/DB-lock/etcd).
Consenso (Raft/Paxos): un leader decide l'ordine; i conflitti sono inferiori, il prezzo è la latitanza.

3. 4 Uomo in tracciato (HITL)

UI per merge/arbitraggio manuale (in particolare contenuti, tariffe, cataloghi).
Anteprima del diffide, spiegazione del criterio, pulsanti «accettare ours/theurs», «unire i campi», «creare un compenso».

4) Pattern per livello di architettura

4. 1 API/REST/gRPC

Ottimistic concertency: 'If-Match: <etag>', 409/412 in caso di conflitto, il client ritraita in base al recente ETag.
Idempotency-Key in POST (pagamenti/ordini).
Semantico 409: informazioni sulla causa e le azioni proposte.

4. 2 Archivi dati

RDBMS: MVCC (snapshot isolation), indici unici, indici parziali.
KV/Doc stores: versioni/revisioni, compare-and-swap (CAS).
Replica multimodale: utilizzare l'orologio di versione/CRDT o «write to leader only» per le entità critiche.

4. 3 Code/streaming

Exactly-once (praticamente «efficiente una volta») è un produttore transazionale + write-to-sink atomico.
Deadup sul console: memorizzazione degli ultimi N id, logica upsert/merge.
Outbox/Inbox pattern - Pubblicazione coerente degli eventi.

4. 4 Configurazioni e IaC

3-way merge in GitOps, policy-gates (OPA/Kyverno) prima dell'applicazione.
Kustomize/Helm - Strategie di merge definite e il divieto di chiavi sconosciute.
Terraform: un piano-diff come segnale di conflitto «drivt vs desired».

5) Algoritmi e esempi

5. 1 3-way merge (semplificato)

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 per la risorsa RESTA

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

Il cliente rilegge, applica il delta allo stato attuale e lo ripete.

5. 3 Conflitto semantico (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 (sketch)

Gli elementi vengono aggiunti con un tag univoco e eliminati con tag specifici.
Il conflitto add vs remove viene risolto con i tag: remove rimuove solo i tag add visibili.

6) Criterio di risoluzione: come formalizzare

1. Ordine origine (priority chain).

2. Strategie per tipi di dati: scalatori/oggetti/array/multimediali.

3. Modello causale: se si utilizzano versioni, Lamport, vector clocks.

4. La semantica delle perdite è ciò che può essere perso con la LWW, dove serve il consenso.

5. Le finestre temporali sono TTL per la deduplicazione, le finestre di idampotenza.

6. Escalation: quando la risoluzione automatica non è consentita, i requisiti di UI/approval.

7. Rimborsi: Strategia SAGA «cancel/compensate» per l'innesco di invarianti.

7) Metriche e SLO

configurts _ total {type} è una frequenza per tipo.
configurs _ resolved _ auto _ ratio è la quota di autorizzazioni automatiche.
mean _ time _ to _ resolution è il tempo medio fino alla risoluzione.
lost _ update _ incidents - Incidenti di aggiornamenti persi.
idempotency _ hit _ rate è la percentuale di chiavi Idempotency che ha funzionato.
divergence _ depth - Profondità della soluzione di replica (vettore di versioni).

Esempio SLO: «Il 99% dei conflitti di sintassi vengono risolti automaticamente per 5 c, il numero semantico per 15 min con HITL».

8) Script pratici

8. 1 Pagamenti

Chiave: Idempotency (Idempotency-Key), OCC in bilico, SAGA per i passaggi invertiti.
Conflitto: Duplice addebito , controllo della versione del saldo, risarcimento parziale.

8. 2 Inventario/biglietti

Opzioni: blocco pessimistico dello slot/spazio; prenotazione ottimistica con TTL in scadenza; coda compare-and-reserve.

8. 3 Contenuti/cartelle

3-way merge + HITL: l'editor seleziona il risultato; Regole auto per campi sicuri (etichette SEO che non influiscono sul prezzo).

8. 4 GitOps/Kubernetes

Render e convalida prima dell'applicazione; reject on unknown keys; il divieto di «--force» senza gelosia.
Rilevamento Drift e policy-enforzed ripristino.

9) Anti-pattern

LWW dappertutto è semplice a costo di perdita di causalità.
I retrai nascosti senza idepotenza sono duplicati a valanga.
Nessun criterio di array esplicito: perdita silenziosa dei punti di configurazione.
Mutex globali sopra le reti, SPOF e blocchi prolungati.
Risarcimenti «ciechi» senza verifica delle cause: conflitti ripetuti.

10) Assegno foglio di implementazione

• Definire i tipi di conflitto nel dominio e gli invarianti.
• Selezionare il meccanismo di versione (ETag/xmin/vector clock).
• Attivare l'idampotenza nei POST critici/commands.
• Impostare il criterio di merge per tipo di dati (scalatori/array/oggetti).
• Attivare i validatori di schemi e i controlli di dominio prima del commit.
• Regolare le metriche dei conflitti e degli alarmi.
• Per le entità critiche è leader/consenso o CRDT.
• Elaborare il flow HITL e UX (diff, commenti, audit log).
• Documentare SLO e procedure di compensazione (SAGA).

11) FAQ

Q: Quando scegliere il CRDT e quando il consenso?
A: CRDT è adatto quando è consentito l'eventual consistency ed è importante l'elevata disponibilità/scrittura locale. Il consenso è per i dati con invarianti rigidi e un ordine di transazione rigoroso (bilanci monetari, diritti di accesso).

La LWW è sufficiente?
A: Per cache, metriche e indici secondari, spesso sì. Per i dati utente e i soldi, quasi sempre no.

Q: Come selezionare una finestra di deduplicazione?
A: Concentrarsi sul ritardo massimo previsto per il recapito + jitter di rete, aggiungere una scorta di 3-5 x p99.

È necessario fare sempre l'HITL?
A: No. HITL lascia per conflitti/conflitti di valore; il resto è automatizzato e logico.

12) Riepilogo

Rilevamento e risoluzione dei conflitti efficaci sono una combinazione di versioni, segni causali, invarianti e politiche chiare, completate da algoritmi appropriati (CRDT/OT/OCC/MVCC/consenso) e osservabilità. I sistemi in cui un conflitto è una situazione «normale» rimangono accessibili e prevedibili; i sistemi in cui un conflitto è un'eccezione si rompono nel momento peggiore. Selezionate un modello, formalizzate le regole e misurate il risultato.