Le organizzazioni con decine di sistemi si trovano solitamente di fronte a un groviglio di connessioni punto a punto: ogni sistema dialoga direttamente con diversi altri, ciascuno con il proprio protocollo e contratto. Il risultato è che modificare un sistema ne compromette molti altri, e aggiungere un nuovo canale, come un'app mobile, richiede mesi di lavoro di integrazione. Quando un team vuole sapere quale sia stata l'ultima transazione di un cliente, deve interrogare tre sistemi e combinare le risposte manualmente. Il livello di integrazione, di fatto, è distribuito in modo invisibile su tutti i sistemi e non appartiene a nessuno.
Questo è importante perché la velocità della trasformazione digitale di un'organizzazione è direttamente legata alla velocità della sua integrazione. Se ogni nuovo prodotto richiede di ricollegarsi ai sistemi centrali, il costo della sperimentazione di nuove idee diventa proibitivo. Ogni connessione diretta è inoltre un punto di sicurezza non presidiato: chi sta chiamando, con quale autorizzazione, con quale frequenza? Senza un livello condiviso, a queste domande si risponde separatamente per ogni connessione, il che in pratica significa che nessuno possiede la risposta completa.
L'architettura preferibile affianca due pattern complementari. L'API gateway è il punto di ingresso unico per le interazioni sincrone: un consumatore invia una richiesta e riceve una risposta nello stesso momento. Il gateway applica in modo uniforme autenticazione, autorizzazione, rate limiting, versionamento e osservabilità. L'architettura event-driven serve le interazioni asincrone: quando accade qualcosa, come l'apertura di un conto o un cambio di indirizzo, il sistema di origine pubblica un evento e qualsiasi sistema interessato lo consuma, senza che la fonte debba sapere chi siano i consumatori. Una coda di messaggi persistente tra i due garantisce che nessun evento vada perso.
La prima considerazione pratica riguarda la progettazione dei contratti. API ed eventi sono entrambi contratti e vanno trattati come tali: con uno schema esplicito, un versionamento esplicito e una regola chiara per distinguere le modifiche compatibili da quelle che introducono rotture. Ad esempio, aggiungere un campo facoltativo a un evento di aggiornamento del cliente è una modifica compatibile, mentre cambiare il tipo di un campo esistente richiede una nuova versione pubblicata accanto alla precedente per un periodo di transizione. Uno schema registry centrale consente ai team di verificare automaticamente la compatibilità prima del rilascio, invece di scoprire una rottura in produzione.
La seconda considerazione riguarda la scelta corretta tra sincrono e asincrono. La regola pratica: se il consumatore ha bisogno della risposta immediatamente per proseguire il proprio lavoro, si usa un'API; se deve solo sapere che qualcosa è accaduto, si usa un evento. Una richiesta di saldo è sincrona. La notifica di una transazione al sistema antiriciclaggio è asincrona. Molti problemi di prestazioni e accoppiamento nelle organizzazioni derivano da interazioni asincrone implementate come chiamate sincrone, in cui un solo sistema lento rallenta l'intera catena.
La terza considerazione riguarda l'osservabilità end-to-end. Quando una richiesta entra dal gateway, attraversa diversi servizi e produce diversi eventi, il team deve poter seguire l'intero percorso con un unico identificativo di correlazione. Tale identificativo deve viaggiare sia negli header delle API sia nei metadati degli eventi. Senza di esso, il debug di un problema si riduce al confronto manuale degli orari nei log di più sistemi, cosa praticamente impossibile nelle ore di punta.
Le insidie più comuni rientrano in alcuni gruppi. Primo, trasformare l'API gateway nella sede della logica di business; il gateway deve applicare le policy, non prendere decisioni di business. Secondo, eventi «grassi» che trasportano l'intero record e vincolano i consumatori alla struttura interna della fonte, oppure eventi «magri» che trasportano solo un identificativo e costringono tutti a richiamare la fonte. Terzo, ignorare ordinamento e duplicazione; un consumatore deve saper riconoscere un evento ripetuto e gestirne uno arrivato fuori ordine. Quarto, non avere un responsabile per il livello di integrazione, che così torna silenziosamente allo stato precedente.
In Niadad, questa triade è implementata come tre piattaforme complementari. Sepehr («سپهر») è l'API gateway aziendale: autenticazione, autorizzazione, rate limiting, versionamento e osservabilità per tutte le interazioni sincrone. Jarian («جریان») è la piattaforma degli eventi: pubblicazione, sottoscrizione e schemi degli eventi con storico conservato. Payam («پیام») è la coda di messaggi persistente che garantisce la consegna e la gestione degli errori per le attività asincrone. Nel programma bancario di Niadad queste tre piattaforme costituiscono la spina dorsale dell'integrazione e si collegano ai livelli di identità, soggetti e dati.
Un API gateway e un'architettura event-driven sono due risposte a due domande diverse, e un'organizzazione matura dispone di entrambi. Ciò che li trasforma in un'unica infrastruttura sono contratti espliciti, identità condivisa e osservabilità end-to-end. Con questi tre elementi, aggiungere un nuovo canale o sistema passa da un progetto di diversi mesi a una questione di giorni. È questa la vera misura di un livello di integrazione: non l'eleganza del suo diagramma, ma quanto poco ostacola il cambiamento successivo.