Salvaguardie per la modifica concorrente: lavorare sullo stesso modello senza sovrascriversi a vicenda

Due persone aprono lo stesso piano dell’organico. Una modifica una data di assunzione, l’altra ritocca una fascia salariale sulla stessa riga, ed entrambe premono salva a pochi secondi di distanza. Senza una salvaguardia, qualunque salvataggio arrivi per secondo vince semplicemente, e la prima modifica scompare senza errore, senza avviso, nulla nell’interfaccia che dica che sia mai avvenuta. Questa è la modalità di guasto che la protezione per la modifica concorrente di Rexfin è costruita per chiudere.

Il problema con un salvataggio semplice

Un’operazione di salvataggio che si limita a scrivere sopra qualunque cosa sia già memorizzata, un semplice upsert, funziona bene con un solo editor. Con più di uno, non ha modo di accorgersi che la riga è cambiata sotto di essa tra il momento in cui è stata caricata e il momento in cui è stata salvata. La seconda scrittura non è sbagliata di per sé; manca semplicemente delle modifiche della prima persona, e appare identica a un normale salvataggio riuscito. Il team dietro Rexfin ha trovato e corretto esattamente questo schema nel registro dell’organico, dove due editor che lavoravano sullo stesso piano potevano sovrascriversi a vicenda tramite l’endpoint di salvataggio senza lasciare alcuna traccia.

Come Rexfin lo intercetta

La correzione è il blocco ottimistico: ogni record di piano porta un numero di versione. Quando carichi un piano, raccogli silenziosamente anche la versione che stai guardando. Quando salvi, quel salvataggio ha successo solo se la versione sul server corrisponde ancora alla versione che avevi visto per ultima. Se qualcun altro ha salvato nel frattempo, la versione si è già spostata, e il tuo salvataggio viene respinto come conflitto invece di essere scritto sopra.

Ciò che conta è cosa succede dopo nell’interfaccia. Un salvataggio respinto non fallisce silenziosamente e non viene nemmeno riprovato silenziosamente in un successo parziale. Fa emergere un messaggio chiaro e difficile da ignorare: qualcun altro ha salvato questo nel frattempo, e devi ricaricare prima di poter continuare. Si tratta di una scelta deliberata: un’interruzione è un risultato migliore di un salvataggio che sembra funzionare ma ha silenziosamente eliminato le modifiche di qualcuno. Se i dati di versione di un record finiscono mai in uno stato incoerente, sono progettati per autoripararsi piuttosto che restare bloccati: si caricano con il piano pulito ma la versione reale intatta, così il salvataggio successivo lo ripara invece di finire bloccato in un ciclo di conflitto permanente.

Oltre il singolo modulo

Una volta dimostrato questo schema sui piani dell’organico, la stessa classe di endpoint di salvataggio è stata controllata più ampiamente nel prodotto, e ha fatto emergere un secondo caso simile di aggiornamento perso nelle impostazioni di conformità, dove un salvataggio leggeva il record esistente, vi univa una modifica e riscriveva tutto quanto. È lo stesso rischio di sovrascrittura silenziosa sotto un nome diverso, ed è ora limitato a toccare solo il campo specifico che viene modificato invece dell’intero record.

Dalla stessa revisione sono emersi alcuni casi limite correlati. Due persone che creavano una nuova versione con nome nello stesso momento potevano altrimenti collidere sul nome; la creazione ora riprova con un suffisso così che entrambi i salvataggi vadano a buon fine invece che uno fallisca del tutto. Spostare un dipartimento sotto un genitore diverso aveva una finestra ristretta in cui due spostamenti simultanei potevano combinarsi in un ciclo vero e proprio, un dipartimento che riporta a se stesso attraverso altri; quell’operazione è ora una singola transazione tutto o niente. E uno più sottile: il primo salvataggio in assoluto di un record nuovo di zecca veniva assegnato allo stesso marcatore di versione che significava “qui non c’è ancora nulla”, il che significava che la prima modifica dopo la creazione di un piano poteva essere sovrascritta proprio come permetterebbe un salvataggio non protetto. I nuovi record ora partono da una versione che non può essere confusa con una vuota.

Dove si colloca nel workspace

Questa salvaguardia gira silenziosamente sotto le parti di Rexfin che un team finance tocca ogni giorno. È ciò che rende i workspace di team effettivamente sicuri da usare con più di un editor alla volta, invece che un invito a pestarsi i piedi a vicenda. Si abbina al workflow di commenti e revisione, dove la discussione avviene accanto alle modifiche invece che in uno strumento separato, e al versionamento e audit trail, il posto dove guarderesti per vedere esattamente cosa è cambiato e quando, se mai un conflitto ti spingesse a controllare. Insieme al resto del tour del prodotto Rexfin, fa parte di ciò che rende un modello condiviso qualcosa in cui un team può effettivamente lavorare nello stesso momento, non solo qualcosa che si toccano a turno.