Transazioni database ecommerce: isolamento, deadlock e retry sicuri

Trattare la concorrenza come parte del percorso ecommerce

Checkout, prenotazione delle scorte, applicazione di un coupon e conferma di un pagamento possono aggiornare gli stessi dati in pochi millisecondi. Una transazione protegge un insieme di operazioni, ma non rende automaticamente corretto ogni ordine di esecuzione. Il risultato dipende dal livello di isolamento, dagli accessi effettuati e dalle regole del motore. Parti quindi dall’invariante di business: una quantità non deve diventare negativa, un coupon monouso non deve essere consumato due volte e un ordine non deve passare a uno stato incompatibile.

Scrivi l’invariante vicino al confine transazionale e identifica tutte le query che lo modificano. Registra anche i lettori che prendono decisioni, perché una lettura apparentemente innocua può osservare uno stato ammesso dal livello scelto ma non adatto al flusso. La domanda utile non è “usiamo le transazioni?”, bensì “quali anomalie possiamo accettare e quale costo operativo sosteniamo per impedirle?”

Disegnare un confine breve e completo

Il confine deve includere tutte le modifiche che devono riuscire o fallire insieme, ma evitare rete, rendering e calcoli non necessari. Una transazione lunga mantiene risorse e può aumentare contesa, attese e probabilità di conflitto. Prepara i dati prima di aprirla, esegui letture e scritture indispensabili in un ordine coerente, chiudi con commit o rollback e restituisci una risposta solo dopo un esito definito.

Scegliere l’isolamento dall’anomalia da evitare

I nomi dei livelli sono simili, ma il comportamento concreto varia tra PostgreSQL, MySQL e SQL Server. Documenta il motore, la versione, la configurazione e la modalità di accesso. Per ogni flusso crea due o tre sequenze concorrenti: due carrelli acquistano l’ultima unità, una richiesta di rimborso si sovrappone alla contabilizzazione del pagamento, un job di riconciliazione legge mentre l’ordine cambia. Verifica se possono apparire letture incoerenti, aggiornamenti persi o decisioni basate su uno stato che non resta valido fino al commit.

Non scegliere il livello più forte per abitudine e non abbassarlo soltanto per ridurre la latenza. Un isolamento più restrittivo può spostare il problema verso aborti e retry; uno meno restrittivo richiede vincoli, aggiornamenti condizionali o blocchi espliciti ben progettati. La scelta è un contratto applicativo da provare con test concorrenti, non una singola impostazione globale.

Usare vincoli e confronti atomici

I vincoli di unicità, le chiavi esterne e le condizioni nell’aggiornamento possono difendere gli invarianti vicino ai dati. Un aggiornamento come “modifica solo se versione e stato sono ancora quelli letti” trasforma una corsa in un esito verificabile. Controlla sempre il numero di righe coinvolte e tratta zero righe come conflitto, non come successo silenzioso. Il meccanismo esatto dipende dal database e va verificato sullo schema reale.

Distinguere deadlock, blocking e timeout

Nel blocking una transazione attende una risorsa detenuta da un’altra; l’attesa può risolversi quando il titolare conclude. Nel deadlock esiste invece un ciclo: ogni partecipante aspetta una risorsa posseduta da un altro. Il database interrompe una vittima per spezzare il ciclo, ma i criteri e i messaggi cambiano tra i motori. Un timeout è ancora diverso: segnala che un limite temporale è scaduto e non prova, da solo, l’esistenza di un deadlock.

Classifica gli errori in base ai codici e agli stati documentati dal driver, non cercando parole in messaggi localizzati. Conserva l’identificativo della transazione applicativa, l’operazione, il numero del tentativo, la durata, la fase e il codice del database, senza registrare dati sensibili. Misura separatamente deadlock, attese lunghe, timeout e fallimenti di serializzazione: aggregarli in un generico “errore database” nasconde interventi diversi.

Ridurre i cicli con ordine e accessi prevedibili

Quando più flussi aggiornano ordini, righe di inventario e pagamenti, fai acquisire le risorse nello stesso ordine logico. Mantieni selettive le query, allinea gli indici ai predicati e limita i batch, perché accessi più ampi possono coinvolgere più righe e trattenere risorse più a lungo. Questa disciplina riduce la superficie dei cicli, ma non autorizza a considerare impossibile un deadlock: il codice deve ancora gestire l’esito previsto dal motore.

Riproduci i conflitti con test che sincronizzano due sessioni su passaggi definiti. Evita test basati soltanto su ritardi casuali: possono passare senza esercitare il punto critico. Verifica l’ordine delle query, gli indici usati e il piano di esecuzione, poi ripeti dopo una modifica di schema o di versione. Un piano diverso può cambiare l’ordine reale degli accessi anche quando il codice applicativo appare invariato.

Ripetere l’intera transazione, non l’ultima istruzione

Dopo un deadlock o un fallimento di serializzazione, lo stato letto in precedenza non è più una base affidabile. Il retry corretto ricomincia dall’inizio: apre una nuova transazione, rilegge i dati, ricalcola la decisione ed esegue tutte le scritture prima di un nuovo commit. Ripetere soltanto l’ultima query può combinare una decisione vecchia con uno stato nuovo e violare proprio l’invariante che si voleva proteggere.

Limitare tentativi, tempo e pressione

Consenti retry solo per errori classificati come transitori. Imposta un numero massimo, un budget temporale complessivo e un backoff con variazione casuale, poi restituisci un esito esplicito quando il budget termina. Un ciclo infinito trasforma la contesa in saturazione e allunga la coda del checkout. Registra quanti tentativi servono e interrompi prima se la richiesta client è scaduta o il sistema è in sovraccarico.

Il blocco di retry deve ricevere una funzione transazionale completa e non trattenere oggetti provenienti dal tentativo precedente. Ogni iterazione ricrea la connessione o il contesto secondo le indicazioni del driver, applica gli stessi limiti e produce un solo risultato. Testa anche l’esaurimento del budget: il chiamante deve sapere se proporre una nuova azione, mettere il lavoro in coda o mostrare un errore recuperabile.

Proteggere gli effetti che il rollback non annulla

Una transazione database non ritira automaticamente un’email, una richiesta a un gateway, un messaggio già pubblicato o un file scritto. Se questi effetti avvengono nel corpo che può essere ripetuto, ogni tentativo può duplicarli. Mantieni nel database l’intenzione, usa un identificatore idempotente stabile e sposta l’invio dopo il commit attraverso un processo affidabile. Per una chiamata esterna inevitabile, applica il contratto di idempotenza del servizio e conserva l’associazione tra richiesta ed esito.

Distingui il fallimento prima del commit, il commit riuscito con una risposta persa e il fallimento dell’effetto successivo. Sono stati diversi e richiedono riconciliazione, non un retry indiscriminato. Il pattern outbox può collegare la modifica di business e l’intenzione di pubblicare un evento nella stessa transazione, ma la consegna può avvenire più volte, quindi il consumatore deve tollerare i duplicati.

Osservare, rilasciare e migliorare senza benchmark inventati

Definisci una baseline sul tuo carico: il tasso di transazioni concluse, i fallimenti per classe, il numero medio di tentativi e un percentile alto o il massimo osservato, il tempo in attesa, la durata totale e le operazioni che consumano il budget. Collega i dati alla versione applicativa, all’impronta della query e al piano di esecuzione senza esporre valori personali. Un aumento dei retry può indicare crescita legittima del traffico, un nuovo ordine di accesso o un indice non più adeguato; serve correlazione, non una soglia universale.

Rilascia una modifica per volta e usa una percentuale controllata del traffico. Prepara un rollback per il codice, lo schema e la configurazione, e conserva un test concorrente nel percorso CI. Per progettare confini transazionali, osservabilità e recupero coerenti con il tuo ecommerce, scopri i nostri servizi per sistemi digitali ed ecommerce. L’obiettivo non è eliminare ogni conflitto, ma renderlo previsto, limitato e verificabile.