Scopritelo prima che arrivi la crescita.
Il sistema regge il carico di oggi. La domanda è che cosa succede a dieci volte tanto, e se la risposta è una messa a punto o una ricostruzione.
Esaminiamo la vostra architettura rispetto alla crescita che state davvero pianificando, e vi diciamo che cosa cede per primo, quanto costa sistemarlo e che cosa potete tranquillamente lasciare com’è. Misuriamo il carico reale invece di guardare lo schema. Non ci candidiamo a fare le correzioni nello stesso incarico, così il giudizio resta indipendente.
Aggiornato novembre 2026
I sistemi raramente cedono in modo uniforme. Una cosa cede per prima.
C’è sempre un collo di bottiglia preciso: una query sul database, un processo che lavora in sequenza, un servizio da cui passa tutto. Tutto il resto ha margine. Trovare quale sia trasforma una preoccupazione vaga in un lavoro con un prezzo.
L’altra metà è sapere che cosa non toccare. I team spesso ricostruiscono le parti che non amano invece di quelle che cederanno, perché l’antipatia si sente più facilmente di quanto si misuri il carico.
Quindi misuriamo, modelliamo la crescita che state davvero pianificando e ordiniamo che cosa sistemare in base a quando farà male.
Che cosa ricevete.
Il vincolo principale, con nome
La singola cosa che cede per prima al carico previsto, con le prove.
In ordine di quando fa male
Che cosa si rompe a due, a cinque, a dieci volte il carico. Così sistemate nell’ordine che serve all’azienda.
Che cosa lasciare stare
Spesso la metà più utile. I team ricostruiscono ciò che li infastidisce invece di ciò che cederà.
Costi alla crescita prevista
Quanto costerà l’infrastruttura se il piano funziona. Raramente modellato prima.
Interventi rapidi separati
Le cose che vale la pena fare questo mese, distinte da quelle che richiedono un trimestre.
Un giudizio onesto sulla riscrittura
A volte la risposta è ricostruire. Più spesso sono tre correzioni precise, e vi diciamo quali.
Un documento scritto
Qualcosa su cui il team può lavorare e che il consiglio può leggere.
Una sessione con i vostri sviluppatori
Così i risultati arrivano alle persone che li metteranno in pratica.
Che cosa cede di solito per primo.
Grosso modo in ordine di quanto spesso lo troviamo come vincolo principale.
| Collo di bottiglia | Segnale prima che ceda | Di solito si risolve con |
|---|---|---|
| Alcune query lente | Le pagine rallentano sotto carico, non sempre | Indici e query riscritte: costa poco |
| Tutto passa da un servizio | Un rilascio tocca tutto | Separare il percorso più usato |
| Processi in background in sequenza | Arretrati nei momenti di picco | Più processi in parallelo e una coda |
| Nessuna cache dove serve | Lo stesso lavoro costoso, ripetuto | La cache: spesso il miglioramento singolo più grande |
| Il database come unico punto | Tutto aspetta il database | Repliche in lettura, poi scelte più difficili |
| Tutto il progetto | Niente cresce senza riscrivere | Raro, e ve lo diciamo chiaramente |
I sistemi dietro il giudizio.
Lavoro per il più grande switch di pagamento condiviso del Pakistan, dove le decisioni di architettura si vedono sotto carico.
Checkout di pagamento per una fintech pakistana, in produzione da oltre quattro anni. Il nostro fondatore ne è stato CTO.
Non ci candidiamo a ricostruire ciò che esaminiamo. Renderebbe inutile il giudizio.
Quando fare una revisione.
State pianificando una crescita vera
Una campagna, un nuovo mercato, un grande cliente. Meglio saperlo prima che arrivi il traffico.
È lento e nessuno sa perché
Di solito una o due cose precise, non un problema generale.
Il team discute se riscrivere
Una lettura indipendente chiude discussioni che vanno avanti da mesi.
Non fa per voi se funziona e non sta crescendo
Un sistema stabile sotto un carico stabile non ha bisogno di una revisione. Vi diremo di risparmiare i soldi.
Come lavoriamo.
Chiediamo che crescita vi aspettate
Numeri reali. Una revisione contro una crescita di cento volte immaginata produce consigli inutili.
Guardiamo il carico reale
Metriche, registro delle query lente, dove va il tempo oggi. Non lo schema.
Troviamo ciò che cede per primo
C’è sempre una cosa. Tutto il resto ha margine.
Modelliamo la crescita
Che cosa si rompe a due, cinque, dieci volte, e quanto costa farlo girare a ciascun livello.
Ordiniamo per urgenza e costo
Compreso che cosa lasciare stare, che di solito è quasi tutto.
Lo ripercorriamo con il team
Così diventa lavoro, non un documento.
Revisione dell’architettura software
6 domande con risposta. Ne avete un’altra? Scriveteci.
Per la maggior parte dei sistemi è un lavoro breve: leggere il codice, guardare metriche reali e parlare con i vostri sviluppatori. Il vincolo è l’accesso più che l’impegno. Una piattaforma molto grande con più team richiede di più; i tempi li concordiamo prima di iniziare.
Sette categorie. Quarantacinque servizi.
Raccontateci il progetto, com’è davvero.
Scriveteci cosa vi serve e dove siete bloccati. Vi rispondiamo entro un giorno lavorativo con domande vere, e se il progetto dovrebbe essere più piccolo di come lo immaginate ve lo diremo.