Architettura per una crescita 10×: come la progettiamo

Quasi tutte le piattaforme vengono costruite per gli utenti che hanno. Il primo giorno è una scelta sensata. Al quattrocentesimo diventa costosa: l’azienda è raddoppiata, ha aperto in un secondo Paese e ha aggiunto una lingua che nessuno aveva previsto.

Pianificare la crescita non vuol dire costruire tutto subito. Vuol dire prendere presto le poche decisioni difficili da cambiare in seguito, e lasciare semplice tutto il resto. Ecco come lavoriamo.

Partire dal traguardo

Prima di scegliere uno stack, mettiamo per iscritto i numeri a cui punta l’azienda: utenti, aree geografiche, transazioni, lingue. Ogni decisione di architettura viene poi verificata su quel traguardo. Il traffico di questo trimestre è solo il punto di partenza.

Non servono numeri precisi. «Una decina di società nel gruppo, tre Paesi, francese, inglese e arabo, qualche migliaio di dipendenti» basta per scartare alcune soluzioni e confermarne altre. Le domande che facciamo sono semplici:

• Quante organizzazioni condivideranno la piattaforma, e i loro dati devono restare rigorosamente separati?
• Di quali lingue e direzioni di scrittura avrà bisogno l’interfaccia?
• Quali regole nazionali si applicheranno (paghe, fisco, localizzazione dei dati)?
• Cosa succede all’azienda se la piattaforma resta ferma per un’ora?

La crescita si progetta, non si improvvisa.

Ogni risposta diventa un vincolo. Un gruppo con più società ha bisogno di un’architettura multi-tenant fin dall’inizio, perché aggiungerla dopo significa mettere mano a ogni tabella e a ogni query. Un prodotto che verrà usato in arabo ha bisogno di layout da destra a sinistra già nelle fondamenta: introdurli a posteriori vuol dire rifare ogni schermata.

Prima i confini

Individuiamo i punti in cui il sistema dovrà dividersi in futuro, come fatturazione, ricerca o notifiche, e tracciamo confini netti già adesso, anche se all’inizio tutto viene rilasciato come un unico servizio.

Un confine di questo tipo è un’interfaccia su cui si appoggia il resto del codice, senza conoscere l’implementazione che c’è dietro:

// a seam today, a service tomorrow
export interface Billing {
  charge(order: Order): Promise<Receipt>
}

Il primo giorno l’implementazione si riduce a poche funzioni nella stessa base di codice. Quando la fatturazione diventa abbastanza complessa da meritare un team, un database o un ciclo di rilascio tutto suo, può spostarsi dietro la stessa interfaccia senza che il resto della piattaforma se ne accorga.

È questa la differenza tra prepararsi alla crescita e sovradimensionare. Non partiamo con una dozzina di microservizi, un bus di messaggi e tre database. Partiamo da un’unica applicazione ben strutturata, con i confini già nel punto in cui un giorno nasceranno i servizi.

Lo stesso principio vale per le integrazioni. Ogni sistema esterno, dal gestionale contabile al provider di identità, sta dietro un adattatore. Così sostituire un fornitore diventa una modifica circoscritta, invece di una migrazione.

Misurare, poi scalare

Ogni piattaforma che lanciamo ha il monitoraggio attivo dal primo giorno. La decisione di scalare si basa sui dati, e le sensazioni restano fuori.

In pratica, prima che il primo utente reale faccia l’accesso, ci sono già tre cose:

• Metriche su tempi di risposta, tassi di errore e operazioni che contano per l’azienda (richieste approvate, fatture emesse).
• Log consultabili per organizzazione, utente e richiesta, per risalire alla causa di ogni problema.
• Avvisi che svegliano qualcuno quando si supera una soglia, prima che se ne accorgano i clienti.

Con queste basi, scalare diventa una serie di piccole decisioni informate: questa query ha bisogno di un indice, quel report va eseguito in background, questa organizzazione merita un database dedicato. Senza, scalare è un azzardo, e gli azzardi di solito costano cari.

Nella pratica

Per una tipica piattaforma aziendale il risultato è volutamente poco spettacolare: un’unica applicazione, multi-tenant fin dalla prima tabella, con single sign-on, audit trail lato server, confini interni chiari, test automatici e monitoraggio. Niente di esotico, e niente da buttare via quando l’azienda cresce.

L’ambizione sta nel piano. La complessità la lasciamo fuori. Se volete che guardiamo il vostro traguardo e vi diciamo quali decisioni contano adesso, prenotate una chiamata.