L'architettura si basa su un sequenziatore di transazioni deterministico che ordina le operazioni utilizzando Orologi Logici Ibridi piuttosto che il tempo fisico, eliminando le dipendenze di scostamento dell'orologio insite nei sistemi basati su TrueTime. Il coordinatore implementa una variante del protocollo Calvin, in cui le intenzioni delle transazioni vengono replicate alla maggioranza dei leader dei shard prima dell'esecuzione, garantendo la serializzabilità attraverso una pianificazione deterministica piuttosto che un blocco distribuito. Le specifiche TLA+ modellano le transizioni di stato del coordinatore, verificando formalmente che il sistema mantenga la sicurezza (serializzabilità rigorosa) e la vivacità (tutte le transazioni impegnate completano alla fine) anche durante le partizioni parziali della rete.
Il coordinatore persiste i log delle transazioni in un WAL (Write-Ahead Log) utilizzando il consenso Paxos per la durabilità attraverso le zone di disponibilità. I proxy degli shard astraggono i motori di archiviazione sottostanti—sia PostgreSQL, MongoDB o Cassandra—presentando un'interfaccia unificata per il motore di esecuzione. La rilevazione dei conflitti impiega un grafo di dipendenza costruito durante la fase di sequenziamento, consentendo l'esecuzione concorrente di transazioni non conflittuali mantenendo l'equivalenza a un ordine seriale.
Una banca d'investimento globale richiedeva la migrazione del proprio sistema di regolamento delle transazioni da un database monolitico Oracle a un'architettura shard che spansiva le regioni AWS e Azure. La sfida critica consisteva nell'assicurare il regolamento atomico delle transazioni che toccavano più classi di attivi memorizzati in tecnologie di database diverse—azioni in PostgreSQL e derivati in ScyllaDB—senza distribuire orologi atomici o fonti di tempo GPS per la sincronizzazione.
Una soluzione proposta ha utilizzato transazioni standard XA con un protocollo di commit in due fasi (2PC) gestito da un gestore di transazioni Narayana. Questo approccio ha offerto una forte coerenza e un supporto ecosistemico maturo, ma ha introdotto un comportamento di blocco in cui un guasto del coordinatore durante la fase di preparazione avrebbe lasciato gli shard con lock indefinitamente, violando i requisiti di vivacità durante l'instabilità della rete cross-cloud.
Un'altra alternativa ha considerato il pattern Saga implementato tramite Axon Framework, utilizzando transazioni compensative per scenari di rollback. Anche se ciò ha fornito alta disponibilità ed evitato il blocco distribuito, ha sacrificato la serializzabilità rigorosa—inaspettato per il regolamento finanziario dove gli stati intermedi non devono mai essere osservabili, e la logica di compensazione per le operazioni di mercato esterne irreversibili si è rivelata proibitivamente complessa.
L'architettura selezionata ha implementato un coordinatore deterministico ispirato a Calvin con verifica formale TLA+. Il sistema ha sequenziato tutte le transazioni di regolamento tramite una macchina a stati replicata utilizzando Raft per il log di coordinamento, quindi le ha eseguite nello stesso ordine in tutti gli shard utilizzando procedure memorizzate idempotenti. Ciò ha eliminato la necessità di blocchi distribuiti durante l'esecuzione e ha consentito il controllo del modello TLA+ per dimostrare matematicamente che il sistema non poteva bloccarsi o perdere i regolamenti durante partizioni di rete arbitrarie.
Il deployment ha portato a una riduzione del 40% della latenza di regolamento rispetto al vecchio sistema Oracle, mantenendo pienamente le garanzie ACID attraverso i cloud. Durante un successivo blackout regionale di AWS, il sistema ha continuato a elaborare le transazioni senza intervento manuale, convalidando le proprietà di vivacità provate formalmente.
Qual è la differenza fondamentale tra serializzabilità rigorosa e linearizzabilità, e perché un coordinatore di transazioni distribuito tipicamente si focalizza sulla prima piuttosto che sulla seconda?
La serializzabilità rigorosa combina la serializzabilità (le transazioni sembrano essere eseguite in un certo ordine sequenziale) con il vincolo di tempo reale della linearizzabilità (le transazioni completano prima che quelle successive inizino). Mentre la linearizzabilità si applica alle operazioni su singolo oggetto, la serializzabilità rigorosa estende questo alle transazioni su più oggetti. I candidati spesso confondono questi concetti, progettando sistemi che garantiscono la linearizzabilità su una singola chiave ma non riescono a prevenire anomalie come lo skew di scrittura attraverso più chiavi. Un coordinatore raggiunge la serializzabilità rigorosa stabilendo un ordine globale di transazioni—spesso attraverso uno strato di sequenziamento o un oracolo di timestamp—mentre la linearizzabilità da sola può essere soddisfatta per shard senza garanzie di ordinamento cross-shard.
Perché il protocollo di commit in due fasi (2PC) blocca indefinitamente durante un guasto del coordinatore, e come il protocollo di commit in tre fasi (3PC) fallisce nel risolvere questo problema durante le partizioni di rete?
Nel 2PC, una volta che un partecipante vota "sì" durante la fase di preparazione, mantiene i lock fino a ricevere la decisione globale di commit/abort dal coordinatore. Se il coordinatore fallisce dopo aver ricevuto tutti i voti ma prima di trasmettere la decisione, i partecipanti rimangono incerti e bloccati, violando la disponibilità. Il 3PC tenta di risolvere questo problema aggiungendo una fase di pre-commit e un progresso basato su timeout, ma durante le partizioni di rete, un partecipante non può distinguere tra un coordinatore fallito e un coordinatore partizionato. Ciò porta a scenari di split-brain in cui diverse partizioni prendono decisioni conflittuali, violando la coerenza. La questione fondamentale è che l'impossibilità di FLP dimostra che il consenso deterministico è impossibile nei sistemi asincroni con anche un singolo processo difettoso, il che significa che qualsiasi protocollo di commit deve scegliere tra il blocco (sicurezza) e la potenziale incoerenza (vivacità) durante alcune modalità di guasto.
Come verifica TLA+ le proprietà di vivacità in un coordinatore di transazioni, e quali operatori di logica temporale specifici esprimono "gradualmente impegna" rispetto a "non perde mai dati"?
TLA+ utilizza la logica temporale per specificare che le cose buone accadono eventualmente (vivacità) mentre le cose cattive non accadono mai (sicurezza). La proprietà di vivacità che tutte le transazioni avviate completano eventualmente è espressa utilizzando l'operatore eventualmente (◇), tipicamente scritto come Initiated(t) ~> Committed(t) (porta a), il che significa che se la transazione t inizia, alla fine si impegnerà o abortirà. Le proprietà di sicurezza come "non perde mai dati" usano l'operatore sempre (□), scritto come □(Committed(t) ⇒ ◇(Query(t) = Value)), il che significa che una volta impegnato, il valore è sempre leggibile eventualmente. I candidati spesso trascurano che il controllo della vivacità richiede assunzioni di equità—l'equità debole (WF_vars(Action)) garantisce che se un'azione rimane abilitata, deve avvenire eventualmente, evitando l'interruzione infinita in cui il coordinatore smette semplicemente di compiere passi. Senza questi vincoli di equità, i modelli TLA+ soddisferebbero trivialmente le proprietà di vivacità non facendo nulla.