In informatica, l'idempotenza è una proprietà di un'operazione in cui l'applicazione che avviene più volte ha lo stesso effetto finale dell'applicazione una sola volta. Se invii la stessa richiesta a un server cinque volte, un sistema idempotente garantisce che il risultato sul server non cambi dopo il primo tentativo riuscito.
Oltre a garantire lo stesso risultato, una caratteristica fondamentale delle operazioni idempotenti è che non producono effetti collaterali con chiamate aggiuntive. Si tratta di un requisito fondamentale per la creazione di sistemi distribuiti resilienti in cui interruzioni di rete intermittenti o timeout potrebbero indurre un client a inviare lo stesso messaggio più di una volta.
Analogia: pensa al pulsante "Su" di un ascensore. Se lo premi una volta, l'ascensore viene chiamato al tuo piano. Se lo premi altre dieci volte mentre aspetti, il risultato è lo stesso: un solo ascensore arriverà al tuo piano. Premere il pulsante più volte non fa arrivare dieci ascensori separati. Al contrario, l'aggiunta di un articolo a un carrello degli acquisti digitale di solito non è idempotente. Se fai clic sul pulsante "Aggiungi al carrello" cinque volte, è probabile che nel carrello finiranno cinque articoli.
Riprova le richieste in modo sicuro dopo un timeout o un'interruzione della connessione senza il timore di duplicare le azioni (come addebitare due volte una carta di credito).
Gli utenti non hanno bisogno di un complesso monitoraggio dello stato per sapere se una richiesta precedente ha avuto esito positivo; possono semplicemente "riprovare fino al successo".
I sistemi distribuiti possono riprendersi dagli arresti anomali riproducendo i log o inviando nuovamente i messaggi persi senza corrompere i dati.
Lo standard REST definisce il comportamento dei diversi tipi di richieste web. Alcuni metodi HTTP sono naturalmente "sicuri" o idempotenti per progettazione, il che significa che la specifica prevede che si comportino in modo prevedibile anche quando vengono ripetuti. Altri sono progettati per creare nuovi dati e richiedono maggiore attenzione per renderli sicuri per i tentativi.
Secondo RFC 9110, diversi metodi standard sono intrinsecamente idempotenti. La ripetizione di queste azioni non dovrebbe modificare lo stato del server oltre la richiesta iniziale.
Alcuni metodi non sono idempotenti perché il loro compito principale è quello di modificare i dati in modo da creare qualcosa di nuovo o modificare una parte di un record esistente.
L'idempotenza è spesso necessaria nei sistemi che creiamo. In alcuni casi, viene gestito per noi. In altri casi, noi sviluppatori dobbiamo intervenire per far sì che ciò accada.
L'esempio più famoso è il problema del "doppio addebito". Se il browser di un utente si blocca mentre sta pagando un volo, potrebbe fare di nuovo clic su "Paga". Un'API di pagamento che utilizza una chiave di idempotenza garantisce che il secondo clic venga riconosciuto come un tentativo. In questo modo, il conto bancario del cliente è protetto e si riducono i costi operativi di gestione dei rimborsi per le transazioni duplicate.
Strumenti come Terraform e Ansible si basano sull'idempotenza. Quando esegui uno script per "creare un bucket di archiviazione da 10 GB", lo strumento controlla lo stato attuale del tuo cloud.
Le API web moderne spesso implementano l'intestazione Idempotency-Key (ora una bozza IETF standardizzata) per consentire agli sviluppatori di creare integrazioni più solide.
Un'operazione "upsert" (update o insert - aggiornamento o inserimento) è una classica operazione di database idempotente. Invece di un semplice "Insert", un upsert dice: "Se questo record esiste, aggiornalo; altrimenti, crealo".
Google Cloud fornisce diversi strumenti che semplificano l'implementazione di questi pattern per gli sviluppatori. La creazione su una piattaforma gestita riduce la quantità di codice "boilerplate" che devi scrivere per mantenere i tuoi dati al sicuro.


Scopri come eseguire il deployment di servizi resilienti e idempotenti su Cloud Run oggi stesso.