Issue 10002 · Sistemi distribuiti
Idempotenza: rendere innocui i duplicati nei sistemi distribuiti
Quando retry, timeout e messaggi duplicati sono normali, il tuo design deve restare corretto comunque.
· 5 min
Obiettivo
Capire perché l'idempotenza è essenziale quando retry, eventi, pagamenti e integrazioni possono produrre la stessa richiesta più di una volta.
Cosa devi progettare davvero
In un sistema distribuito non puoi controllare quanti tentativi arriveranno, ma puoi controllare l'effetto di quei tentativi. Il punto non è impedire i duplicati: è fare in modo che ripetere la stessa intenzione di business produca un solo effetto osservabile. In pratica, devi agganciare l'operazione a un'identità stabile della richiesta, come una idempotency key o una combinazione di identificatori di business, e salvare lo stato di elaborazione in modo che un retryGlossarioRetryUn nuovo tentativo eseguito dopo un fallimento che potrebbe essere transitorio.Apri la voce completa riceva una risposta coerente invece di rieseguire l'azione. Questo è particolarmente importante per operazioni come creazione ordini, conferma pagamenti, emissione fatture o publish di eventi che attivano side effect a cascata.
I compromessi che non puoi ignorare
L'idempotenzaGlossarioIdempotenzaLa proprietà per cui ripetere un’operazione non produce effetti aggiuntivi indesiderati.Apri la voce completa semplifica la resilienzaGlossarioResilienzaLa capacità di continuare a produrre risultati utili quando componenti falliscono o le condizioni degradano.Apri la voce completa, ma introduce costi di progettazione e di storage. Devi decidere per quanto tempo conservare la chiave, quando considerare una richiesta definitivamente completata e quale risposta restituire ai retry. Se tieni troppo poco stato, rischi di non riconoscere duplicati tardivi; se tieni troppo, aumenti complessità operativa e pressione sul database o sul cache layer. C'è anche un trade-offGlossarioTrade-offUno scambio in cui migliorare un risultato ne indebolisce o ne rende più costoso un altro.Apri la voce completa semantico: una chiave deve rappresentare l'intenzione di business, non il singolo tentativo tecnico. Se la chiave è troppo granulare, i duplicati passano; se è troppo larga, puoi bloccare operazioni legittime distinte. In molte architetture enterprise, questa scelta va allineata con product owner, operations e team di integrazione, perché impatta sia la correttezza applicativa sia la capacità di fare supporto.
Esempio enterprise: conferma pagamento ritentata
Immagina un OMS che riceve la conferma di pagamento per un ordine. Il servizio aggiorna lo stato da pending_payment a paid, pubblica un eventoGlossarioEventoUna dichiarazione durevole che qualcosa di significativo è già accaduto.Apri la voce completa e avvia il fulfillment. La chiamata però va in timeoutGlossarioTimeoutUn limite definito a quanto un’operazione attende prima di considerare il tentativo non riuscito.Apri la voce completa verso il gateway, quindi il client o l'orchestratore ritenta. Senza idempotenza, il secondo tentativo può generare due eventi di pagamento, due avvii di fulfillment o due email al cliente. Con una chiave costruita su orderId e paymentTransactionId, il sistema riconosce che il secondo messaggio rappresenta la stessa intenzione di business, restituisce lo stesso esito e non ripete gli effetti collaterali. Questo approccio è coerente con il pattern Transactional Outbox: prima rendi affidabile la pubblicazioneGlossarioPubblicazioneL’azione esplicita che rende disponibile ai lettori una issue approvata.Apri la voce completa dell'evento, poi rendi sicuro il consumo rispetto ai duplicati.
Per approfondire
Fonti autorevoli per approfondire il tema dell'idempotenza e dei retry nei sistemi distribuiti. • Idempotent and Safe Methods — RFC 7231, IETF — https://www.rfc-editor.org/rfc/rfc7231 • Designing Data-Intensive Applications — Martin Kleppmann, O'Reilly Media — https://dataintensive.net/ • Idempotent Receiver Pattern — Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns — https://www.enterpriseintegrationpatterns.com/patterns/messaging/IdempotentReceiver.html