Compromessi di progettazione e CAP

CAP sostiene che, in un contesto di separazione della rete (Partition, P), un sistema distribuito non può garantire sia una forte coerenza (Consistency, C) che una disponibilità (Availability, A). Se si dispone di un P, è necessario selezionare un CAP o un PA. In assenza di divise, il vincolo non è valido, ma altri compromessi - soprattutto il ritardo (latency) e il costo.

L'ingegneria pratica va oltre il CAP: importante per PACELC (se P - scegliamo C o A; altrimenti - scegliamo tra Latency e Consistency), modelli di coerenza, SLA/SLO, yuskace e rischi aziendali.

1) Definizioni di base (senza filosofia)

Coerenza (C): tutti i clienti vedono lo stesso risultato come se le operazioni fossero state eseguite in sequenza (linearità/strong consistency).
Disponibilità (A) - Ogni richiesta di un nodo mancante viene completata in tempi ragionevoli, anche se separata.
Divisione (P): perdita o deterioramento significativo della connessione tra nodi/cluster regionali in pratica, «inevitabile» su larga scala.
PACELC: seleziona C o A in P; else (quando non c'è un P) seleziona L (ritardo basso) o C (coerenza forte).

2) Immagine intuitiva della selezione

P (la coerenza è più importante): quando si separano alcune richieste, respingiamo/blocchiamo per non violare gli invarianti. Adatto per denaro, transazioni, contabilità dei saldi.
PA (la disponibilità è più importante): rispondiamo sempre, ma consentiamo la separazione temporanea, quindi contrattacciamo i conflitti (CRDT/regole di merge). Adatto per soz fides, contatori di like, profili di cache.
CA (contemporaneamente C e A): è possibile solo in assenza di P - per ora la rete è sana. Il funzionamento effettivo di CA è uno stato temporaneo, non una proprietà di progettazione.

3) PACELC: non dimentichiamo il ritardo

• Una forte consistenza tra regioni = quorum intercontinentali ⇒ decine o centinaia di ms al p95.
• Letture locali (bassa L) = garanzie più deboli (read-my-writes, bounded staleness, evangual).
• PACELC aiuta a spiegare perché «veloce e rigorosamente» è raro che la luce non sia immediata, ma che i quorum crescano con la piegatura della rete.

4) Modelli di coerenza (spettro rapido)

Linearizable/Strong - Come un ordine sequenziale.
Serializable equivale a un ordine transazionale sequenziale (superiore al livello di record).
Read-your-writes/Monotonic reads - Il client legge il nuovo valore dopo la propria scrittura.
Bounded staleness - Le letture non sono più lontane da N versioni/Filet.
Eventual consistency: tutte le copie convergono nel tempo; I conflitti devono essere risolti.

5) Pattern CAP e PA in prodotti e protocolli (concettuale)

Approcci CAP: registri/leadership quorum (Raft/Paxos), transazioni rigorose, posizioni globali leader, replica sincrona. Il prezzo è il rifiuto di parte delle richieste a P e l'aumento dei ritardi.
Approcci PA: multi-master/multi-leader, CRDT, gossip-distribuzione, replica asincrona, risoluzione dei conflitti (LWW, ore vettoriali, funzioni di dominio). Il prezzo è la coerenza temporanea e la complessità delle regole di dominio.

6) Compromessi nella regione multi

Leader globale: logica semplice, ma le regioni «lontane» pagano con latenza; per P - Blocco dei record.
Leader locali + asincrone (PA): scrittura rapida localmente, quindi replica le modifiche in conflitto richiedono merge.
Geo-partitioning: i dati «vivono» sono più vicini all'utente/giurisdizione; Le regioni crociate sono solo apparecchiature.
Dual-write è vietato senza saghe/CRDT, altrimenti vengono generati fantasmi e doppi prelievi.

7) Ingegneria invarianti e soluzioni aziendali

Innanzitutto invarianti: ciò che non può essere infranto (doppio consumo, negativo residuo, univoco chiave) e ciò che «subisce» eventual (contatore di visualizzazioni, raccomandazioni).

• L'invariante «rigido» della CPU per le operazioni appropriate.
• Invariante «morbido» → PA con conseguente contrazione.

8) Tecniche di mitigazione dei compromessi

Cache e CQRS - Lettura tramite cache/proiezione ravvicinata (AP), scrittura su registro rigoroso (COP).
RPO/RTO come lingua di compromesso: quanti dati possono essere persi (RPO) e come recuperare rapidamente (RTO).
ID e orologi coerenti: timestamp monotono (approcci Hybrid/TrueTime), ULID/Snowflake.
Sags/TSS - compensazioni aziendali invece di blocchi globali.
CRDT e merge di dominio per collezioni, contatori, «ultime vittorie».
Bounded staleness - Bilanciamento UX e precisione.

9) Osservazione, SLO e gestione degli incidenti

SLO di latenza (p50/p95/p99) separatamente per letture/record e regioni.
SLO per la disponibilità in base al feelover della regione.
Lag repliche/conflittualità: percentuale di conflitti, tempo medio di risoluzione.
Alert con il segno P: aumento dei timeout dei canali interregionali, aumento degli errori del quorum.
Modalità Delrade: modalità read-only, servizio locale seguito da un murge, disattivazione delle funzioni «costose».

10) Assegno-foglio di scelta della strategia

1. Quali invarianti non possono essere violati? Cosa permette l'eventual?
2. È necessaria una registrazione a bassa latenza crociata-regionale?
3. Quali sono gli obiettivi SLO (latity/disponibilità) e i costi (egress/replica)?
4. Il manual merge o solo il distributore automatico (CRDT/regole)?
5. Qual è il profilo di errore di rete: frequenza, durata, blast radius?
6. Esiste una localizzazione legale dei dati (residency)?
7. Quale modello di coerenza è accettabile per ogni tipo di dati/operazione?
8. Come vedrete, lagi, conflitti, quorum?
9. Cosa fa il sistema con P: blocca, degrado, divide il traffico?
10. Qual è il piano di ripristino e rimpatrio dei dati dopo P?

11) Errori tipici

Inseguire «CA per sempre». La prima P dovrà scegliere, meglio in anticipo.
Un multi-master globale senza regole di merja. I conflitti mangiano dati e fiducia.
Una forte consistenza dappertutto. Quorum eccessivi colpiscono p95/p99 e budget.
Dual-write senza transazioni/saghe. Invarianti e fantasmi persi.
Ignora PACELC. La latitanza soffre in tempo di pace, la disponibilità in tempesta.
La telemetria zero di conflitti e laghe. I problemi sono visibili solo all'utente.

12) Ricette veloci

Addebito/saldo: deposito CC con quorum; registrazioni solo tramite il leader; le letture possono essere memorizzate nella cache, ma negli UX critici - read-your-writes.
Contenuti/FID: Replica PA + CRDT/Regole di Merge; P - Servire localmente, poi colpire.
SaaS globale: geo-partitioning per tenant/region; operazioni rigorose nella regione «domestica», report/ricerca tramite proiezioni asincroni (PA).
Segnale Real Time: Anycast/edge + bus AP; i comandi critici passano attraverso un canale confermato.
Controllo/registro: l'unica fonte di verità (append-only) con garanzie CC, intorno alla cache e alla proiezione.

13) Mini-riferimento architettura (verbale)

Write-core (COP) - Leader + replica quorum, invarianti rigorosi, saghe per gli effetti interserver.
Read-plane (AP) - Viste materializzate, cache, indici search, aggiornamento asincrono.
Geo-routing: gli utenti entrano nella regione «domestica»; P - modalità locale + replica successiva.
Conflitto-motore: CRDT/regole; Registro dei conflitti e strumenti di risoluzione manuale.
Trailing quorum, lagi, mappa degli incidenti della rete.

14) Matematica pratica dei ritardi (valutazione semplice)

Ottica 5 ms per 1000 km (RTT ancora più grande). Quorum intercontinentali p95 facile> 150-250 mc.
Qualsiasi Strong globale da scrivere è una richiesta costosa. Se l'UX richiede <100-150 ms, si pensi alle conseguenze locali write-home + asincrone.

15) Regole di separazione

Percorso COP - Blocca i record fuori dal quorum; includere read-only Dare gli stati onesti all'utente.
Percorso PA - Manutenzione locale etichettare le versioni durante il ripristino - un misuratore di misura; conflitti in coda di analisi.

Conclusione

CAP non è un dogma, ma un promemoria: la divisione della rete è inevitabile, e il progetto deve scegliere in anticipo cosa sacrificare nella tempesta - disponibilità o rigorosa coerenza. PACELC aggiunge un asse chiave di ritardo in tempo chiaro. Combinate le strategie: tenete il nucleo CAP dove gli invarianti sono sacri e il piano AP dove la velocità e la stabilità sono più importanti. Inserire la telemetria, i piani di degrado e i processi di merja - e il sistema conserva sia i dati che la fiducia utente.