Che cos'è l'idempotenza?

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.

Vantaggi principali dei sistemi idempotenti

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.

Metodi HTTP idempotenti e non idempotenti

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.

Metodi idempotenti (GET, PUT, DELETE)

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.

  • GET: questo metodo recupera i dati. Poiché non cambia nulla sul server, puoi chiamarlo un milione di volte e la risorsa rimane la stessa.
  • PUT: questo metodo sostituisce completamente una risorsa. Se aggiorni l'email di un utente a "user@example.com" tre volte, lo stato finale è comunque che l'email è "user@example.com".
  • DELETE: rimuove una risorsa. Se elimini "Ordine n. 123" e poi provi a eliminarlo di nuovo, l'ordine rimane eliminato. Il risultato (l'ordine è scomparso) rimane lo stesso.

Metodi non idempotenti (POST, PATCH)

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.

  • POST: gli sviluppatori utilizzano POST per creare nuove risorse. Senza la logica di idempotenza, l'invio della stessa richiesta POST due volte (come "Invia pagamento") di solito comporterebbe due record separati e due addebiti al cliente.
  • PATCH: questo metodo applica aggiornamenti parziali. Sebbene possa essere reso idempotente, spesso non lo è per impostazione predefinita perché la ripetizione di una modifica relativa (come "aggiungi 5 al saldo") comporterebbe un valore finale diverso ogni volta che viene chiamata.

Come implementare un'API idempotente

  1. Genera una chiave univoca: il client crea una stringa univoca (come un UUID) e la include in un'intestazione HTTP personalizzata.
  2. Intercetta e convalida: il server controlla un datastore ad alta velocità come Memorystore per vedere se la chiave è stata elaborata di recente.
  3. Gestisci lo stato: se la chiave è nuova, elabora la richiesta e salva il risultato. Se si tratta di un duplicato, restituisci immediatamente il risultato memorizzato senza eseguire nuovamente la logica di business.

Casi d'uso comuni per l'idempotenza

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.

  • Azione richiesta allo sviluppatore: devi implementare una chiave di idempotenza (spesso un UUID) nella tua richiesta API per assicurarti che il secondo clic venga riconosciuto come un tentativo, proteggendo il conto bancario del cliente

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.

  • Gestita per te: l'idempotenza viene gestita dallo strumento IaC stesso; in qualità di sviluppatore, non devi scrivere logiche aggiuntive per impedire la duplicazione delle risorse

Le API web moderne spesso implementano l'intestazione Idempotency-Key (ora una bozza IETF standardizzata) per consentire agli sviluppatori di creare integrazioni più solide.

  • Azione richiesta dallo sviluppatore: quando crei il backend, devi implementare la logica per intercettare queste chiavi, verificare i tentativi precedenti e restituire la risposta memorizzata nella cache

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".

  • Gestita per te: questa logica viene gestita in modo nativo dal motore del database, garantendo che i record convergano allo stato corretto indipendentemente dal numero di volte in cui viene eseguito lo script

Risolvi le tue sfide aziendali con Google Cloud

I nuovi clienti ricevono 300 $ di crediti senza costi da spendere su Google Cloud.
Parla con un esperto delle vendite di Google Cloud per discutere della tua sfida unica in modo più dettagliato.

Creazione di microservizi affidabili su Google Cloud

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.

  • Cloud Run: quando utilizzi Cloud Run per elaborare eventi da Pub/Sub, ricorda che Pub/Sub potrebbe consegnare i messaggi più di una volta per impostazione predefinita. La scrittura di codice idempotente nei servizi Cloud Run è un requisito per garantire che gli agenti di AI o le pipeline di dati non elaborino lo stesso evento due volte.
  • Nota su Pub/Sub: sebbene la consegna predefinita sia basata su push, la consegna exactly-once è disponibile per le sottoscrizioni basate su pull. È utile conoscere questi due tipi per scegliere il giusto livello di complessità per il tuo servizio.

Pronta per la creazione

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

Google Cloud