Detectarea și soluționarea conflictelor

1) Ce este considerat un conflict

Un conflict este o situație în care două sau mai multe surse de schimbare pretind stări incompatibile ale aceleiași entități, resurse sau invariante.

Sintactic: suprapunerea modificărilor la un fișier/cheie (îmbinarea conflictului în Git, coliziunea patch-urilor în Kustomize).
Semantic: un document corect conform schemei încalcă invariantul de afaceri (suma debitului ≠ creditul, limita depășită).
Operațional/temporal: scriu/citesc curse, duplicat evenimente, cauza-efect discrepanță.
Domeniu: operațiuni concurente pe resursă (vânzare de bilete duble, mărfuri overbook).

Sarcina: de a detecta conflictul cât mai curând posibil, de a explica cauza sa și de a alege în condiții de siguranță una dintre acțiunile: recuperare automată, retray, fuziune, compensare, escaladare.

2) Mecanisme de detectare

2. 1 Versionarea și compararea stării

ETag/If-Match în REST, rowversion/xmin în DB - detectarea actualizării pierdute.
3-way fuziune (baza, a noastră, a lor) - evidențierea editări incompatibile.
Suma de control/Hash de câmp/document - comparație ieftină.

2. 2 Etichete temporale și cauzale

Ceas cu lampă: comanda totală „aproximativă în timp”.

2. 3 Invarianți și constrângeri

Scheme și validatoare (JSON Schema/OpenAPI) - valabilitate sintactică.
Invariante: unicitate, non-negativitate, echilibru, reguli ACL.
Verificări de integritate: indici FK/UNIQUE/EXCLUDE, constrângeri parțiale.
Domeniul afirmă în codul/politicile (OPA/Kyverno/Conftest).

2. 4 Detectarea în fluxurile de evenimente

Idempotency Key/Dedup Store (de ex. Redis/DB cu TTL): respingerea take-urilor.
Tranzacțional/Exact-o dată în streaming: id-ul tranzacțional, epoca producătorului, consumer-offset.
Detectarea decalajului de secvență: lacune, repetări (n, n + 1, n + 1).

2. 5 Observabilitate și alarmă

Eroare/Coliziune/Retray Prometrica.

3) Strategii de rezoluție

3. 1 Complet automat (sigur prin definiție)

CRDT (tipuri de date replicate fără conflicte): G-Counter, PN-Counter, OR-Set, LWW-Register, Map/Graph CRDT.

asigurarea convergenței fără coordonare; alegerea semanticii de pierdere/retenție este importantă.
Operații comutative: aplicate în orice ordine (incremente, anexe jurnal).
Manipulanți idempotenți: repetarea nu schimbă rezultatul (upsert prin cheie, put-if-absent).
Fuzionarea optimistă a structurilor: „fuziune profundă + politică” cu ordine deterministă.

3. 2 Semi-automate (cu politica)

Reguli de îmbinare + matrice în 3 direcții („înlocuiți” adăugați „uniqueBy (cheie) | patchBy (cheie)”).
LWW (Last-Write-Wins): simplu, dar risc de pierdere a corectitudinii cauzale.
Prioritățile surselor sunt "interactive input> config from file> defaults'.
Reguli de afaceri: „dacă limita este depășită - confirmare/compensare parțială”.

3. 3 Coordonarea

OCC/MVCC (blocare optimistă/multi-versiune): reconciliere versiune, retray.
Încuietori pesimiste: "SELECTAȚI... PENTRU UPDATE ', încuietori distribuite (Redlock/DB-lock/etcd).
Consens (Raft/Paxos): un lider decide ordinea; există mai puține conflicte, prețul este latența.

3. 4 Persoană în buclă (HITL)

UI pentru fuziuni manuale/Arbitraje (în special conținut, Tarife, Cataloage).
Previzualizarea diferitelor, explicarea politicii, butoanele: „acceptați câmpurile noastre/ale lor”, „îmbinați câmpurile”, „creați compensații”.

4) Modele de straturi de arhitectură

4. 1 API/REST/gRPC

Concurență optimistă: 'If-Match: <etag>', 409/412 în caz de conflict → clientul se retrage ținând cont de ETag proaspăt.
Idempotency-Key în POST (plăți/comenzi).
Semantic 409: Comunicați motivul și acțiunile propuse.

4. 2 Depozite de date

RDBMS: MVCC (izolare instantanee), indici unici, indici parțiali.
KV/Doc stochează: versiuni/revizii (rev), comparați-și-swap (CAS).
Replicare multi-master: Utilizați/CRDT sau scrieți liderului numai pentru entitățile critice.

4. 3 Cozi/Streaming

Exact o dată (practic - „efectiv o dată”): producător tranzacțional + scriere atomică la chiuvetă.
Dedup pe consolă: stocarea ultimei logici N id, upsert/îmbinare.
Modelul Outbox/Inbox: publicarea consecventă a evenimentelor.

4. 4 configurații și IaC

3-way fuziona în GitOps, policy-gates (OPA/Kyverno) înainte de utilizare.
Kustomize/Helm: strategii deterministe de îmbinare și interzicerea „cheilor necunoscute”.
Terraform: plan-diff ca un semnal de conflict „drift vs wanted”.

5) Algoritmi și exemple

5. 1 fuziune în 3 sensuri (simplificată)

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

Clientul recitește, aplică delta la starea actuală, și se repetă.

5. 3 Conflict semantic (invariant)

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: SAU-Set (schiță)

Elementele sunt adăugate cu o etichetă unică, ștergere - pentru o anumită etichetă.
Conflictul „add vs remove” este rezolvat prin utilizarea tagurilor de eliminare pentru a elimina numai etichetele de adăugare vizibile.

6) Politica de rezoluție: cum se formalizează

1. Lanţul prioritar.

2. Strategii după tipul de date: scalare/obiecte/matrice/multimedia.

3. Model cauzal: utilizați versiuni, Lamport, ceasuri vectoriale.

4. Semantica pierderii: ce se poate pierde în LWW, unde este nevoie de consens.

5. Ferestre de timp: TTL pentru deduplicare, ferestre idempotency.

6. Escaladarea: atunci când rezoluția automată este interzisă, cerințele pentru UI/omologare.

7. Compensații: Strategiile SAGA „anulează/compensează” pentru reasamblarea invarianților.

7) Metrics și SLO

conflicts_total{type} este frecvența după tip.
conflicts_resolved_auto_ratio - cota de auto-permise.
mean_time_to_resolution este timpul mediu de decontare.
lost_update_incidents - Incidente de actualizări pierdute.
idempotency_hit_rate - proporția cheilor de Idempotency care au funcționat.
divergence_depth este adâncimea divergenței replica (vectori versiune).

Exemplu SLO: „≥ 99% din conflictele sintactice sunt rezolvate automat în ≤ 5 secunde, conflicte semantice în ≤ 15 minute cu HITL”.

8) Scenarii practice

8. 1 Plăți

Cheie: Idempotency-Key, OCC pe echilibru, SAGA pentru pași reversibili.
Conflict: extragere dublă → dedup + verificarea versiunii bilanțului → compensare parțială.

8. 2 Inventar/Bilete

Opțiuni: slot pesimist/blocare scaun; rezervare optimistă cu TTL expirată; comparați-și-rezervă coadă.

8. 3 Conținut/cataloage

3-way fuziona + HITL: editor selectează total; Reguli auto pentru câmpurile „sigure” (etichete SEO care nu afectează prețul)

8. 4 GitOps/Kubernetes

Redarea și validarea înainte de aplicare; respinge pe chei necunoscute; interzicerea „--force” fără revizuire.
Detectarea în derivă și rostogolirea aplicată de politici.

9) Anti-modele

LWW peste tot: simplitate cu costul pierderii cauzalității.
Retrocedări ascunse fără idempotență: duplicate asemănătoare avalanșelor.
Nici o politică de array explicită - pierderea silențioasă a punctelor de configurare.
Mutexuri globale pe partea de sus a rețelelor: SPOF și încuietori lungi.
Compensații „oarbe” fără audit de cauză: conflicte repetate.

10) Lista de verificare a implementării

• Definiți tipuri de conflicte de domeniu și invarianți.
• Selectați mecanismul de versionare (ceas ETag/xmin/vector).
• Activați idempotența în POST/comenzi critice.
• Setați politica de îmbinare după tipul de date (scalare/matrice/obiecte).
• Activați validatoare schema și verificări de domeniu pre-comite.
• Configurați valorile de coliziune și alertă.
• Pentru entitățile critice - lider/consens, sau CRDT.
• Lucrați fluxul HITL și UX (diff, comentarii, jurnal de audit).
• SLO-uri de documente și proceduri de compensare (SAGA).

11) ÎNTREBĂRI FRECVENTE

Î: Când să alegeți CRDT și când să alegeți consensul?
R: CRDT este potrivit atunci când o eventuală consecvență este acceptabilă și disponibilitatea ridicată/intrările locale sunt importante. Consens - pentru datele cu invarianți rigizi și ordinea strictă a operațiunilor (solduri de numerar, drepturi de acces).

Î: Este suficient LWW?
R: Pentru cache-uri, valori și indici secundari - adesea da. Pentru datele utilizatorilor și bani, aproape întotdeauna nu.

Î: Cum selectez o fereastră de eliminare a duplicatelor?
R: Concentrați-vă pe întârzierea maximă așteptată de re-livrare + jitter de rețea, adăugați o marjă de 3-5 × elementul 99.

Î: Ar trebui să faceți întotdeauna HITL?
R: Nu. Lăsați HITL pentru conflicte litigiu/valoare automatiza și jurnal restul.

12) Totaluri

Detectarea și rezolvarea eficientă a conflictelor este o combinație de versioning, etichete cauzale, invarianți și politică clară completată de algoritmi adecvați (CRDT/OT/OCC/MVCC/consens) și observabilitate. Sistemele în care conflictul este o situație „normală” rămân accesibile și previzibile; sistemele în care conflictul este o „excepție” se descompun în cel mai rău moment posibil. Selectaţi un model, formalizaţi reguli şi măsuraţi rezultatul.