Sincrono o asincrono? Come scelgo l'integrazione verso sistemi esterni

01Una sola domanda da farsi

L'utente che ha premuto il pulsante ha bisogno della risposta del sistema esterno per poter continuare? Se sì, la chiamata è sincrona e devi progettare timeout, messaggio d'errore comprensibile e comportamento in caso di risposta parziale.

Se no — e capita più spesso di quanto si pensi — la chiamata va in coda. L'utente riceve conferma della presa in carico, il sistema esterno viene contattato quando è disponibile, e i ritentativi sono un problema dell'infrastruttura, non dell'utente.

02L'asincrono non è gratis

Metti una coda e ottieni resilienza, disaccoppiamento e ritentativi; in cambio devi gestire idempotenza, ordine dei messaggi, messaggi non processabili e visibilità dello stato. Se non hai una schermata che dice all'operatore «questa richiesta è ancora in attesa», hai spostato il problema, non risolto.

Per questo ogni integrazione asincrona che progetto nasce con tre cose: una chiave di idempotenza, una coda di scarto per i messaggi che non passano e uno stato consultabile dall'interfaccia.

03Il caso della reportistica

La generazione di documenti è l'esempio perfetto. Un report che aggrega dati distribuiti su più microservizi non va prodotto dentro la richiesta HTTP dell'utente: si accoda, si genera, si notifica quando è pronto. Con JasperReports questo significa separare il template dal recupero dati e trattare il PDF come un artefatto, non come una risposta.

Il vantaggio secondario è che un artefatto si può conservare, riscaricare e allegare a un audit. Una risposta HTTP no.

04La regola che uso

Sincrono dove serve una risposta immediata per decidere; asincrono dove servono resilienza, ritentativi e disaccoppiamento. E in entrambi i casi: nessuna integrazione senza un comportamento definito per il caso in cui l'altro sistema è giù. Quel caso non è un'eccezione, è mercoledì.