GitHub cambia architettura: quando più repliche rallentano i push

C’è una decisione architetturale che sembra inattaccabile: se un servizio riceve troppe richieste di lettura, aggiungiamo repliche. Più copie, più capacità, più affidabilità. Peccato che, in certi sistemi, ogni replica aggiunta per alleggerire le letture finisca per appesantire le scritture. Non è un paradosso filosofico. È un problema di progettazione molto concreto, ed è uno dei motivi per cui GitHub sta ricostruendo il proprio livello infrastrutturale dedicato a Git.

La novità non è che GitHub abbia scoperto il cloud o che gli agenti AI siano diventati improvvisamente magici. È che un’architettura costruita per garantire contemporaneamente durabilità e prestazioni ha finito per legare due esigenze che dovrebbero poter crescere separatamente. Finché il carico rimaneva compatibile con quel compromesso, il sistema funzionava. Quando cambia il profilo delle richieste, il compromesso presenta il conto.

Cinque copie dello stesso repository: una buona idea, fino a un certo punto

Nel resoconto tecnico pubblicato da GitHub Engineering il 6 ottobre 2026, Brian Celenza descrive l’architettura chiamata Spokes. Ogni repository viene conservato su più file server, normalmente cinque, ciascuno con una copia completa sui propri dischi locali. Queste copie offrono ridondanza e consentono di distribuire le letture: due benefici reali, non errori di progettazione.

Il problema arriva quando una push deve aggiornare lo stato del repository. Per mantenere una visione consistente tra interfaccia web, API e processi CI, il sistema usa un protocollo di commit a tre fasi con quorum. Le copie non sono semplici cache sacrificabili: partecipano al meccanismo che rende durevole e coerente la modifica.

Aggiungere un file server per servire più fetch significa quindi aggiungere un partecipante al lavoro di scrittura. GitHub spiega che la push è vincolata alla replica più lenta del proprio insieme. È una semplificazione del comportamento operativo riportato dall’azienda, non una legge universale di tutti i protocolli a quorum: ciò che conta è che, in questo disegno specifico, capacità di lettura e costo della scrittura crescono insieme.

Quando usi la stessa componente per risolvere due problemi diversi, prima o poi uno dei due decide quanto puoi scalare l’altro.

Gli agenti non creano il difetto. Lo rendono impossibile da ignorare

La pressione arriva da un cambiamento misurabile nel modo di utilizzare i repository. Secondo i dati pubblicati da GitHub, l’attività Git mensile è passata da 218,2 miliardi di eventi nel settembre 2025 a 473,3 miliardi nell’agosto 2026. Nel settembre 2026 sono stati registrati 7,38 miliardi di commit, oltre cinque volte quelli dell’anno precedente. Le push mensili sono cresciute da 690 milioni a 3,35 miliardi.

Questi numeri descrivono l’intera piattaforma e non dimostrano, da soli, quale percentuale della crescita sia causata dagli agenti. GitHub attribuisce però ai workflow agentici una parte importante del nuovo profilo di carico. Un agente può lavorare in cicli serrati, salvare checkpoint frequenti, aprire branch e inviare modifiche senza le pause naturali di un essere umano. La latenza di una singola push, irrilevante per chi controlla la posta mentre aspetta, diventa tempo perso ripetuto migliaia di volte.

A questo si aggiunge l’effetto a cascata. Una modifica può attivare pipeline, analisi statiche, controlli e letture dello stesso branch da molti client. GitHub dichiara 3,26 miliardi di esecuzioni di Actions nel settembre 2026, più di quattro volte il volume dell’anno precedente. Non cresce soltanto il numero delle operazioni: cambia il rapporto fra scritture, letture successive e attività di manutenzione.

Avevo già affrontato il lato organizzativo in un articolo sul coordinamento di molti agenti che lavorano con Git. Qui il problema è differente e più vicino al metallo: anche un’orchestrazione impeccabile può rimanere in attesa di un’infrastruttura che rende ogni aggiornamento inutilmente costoso.

La soluzione non è avere meno repliche. È assegnare loro un mestiere diverso

GitHub sta progettando una separazione più netta tra persistenza autorevole e capacità di calcolo. I dati durevoli del repository risiedono in Azure Blob Storage; worker più leggeri gestiscono il servizio e la cache delle letture. In questo modello, aumentare la capacità per fetch e clone non richiede di aggiungere altre copie durevoli che partecipano alla stessa scrittura.

Non significa che i dati smettano di essere replicati. Significa che la ridondanza viene affidata al livello di storage, mentre i worker applicativi possono essere aggiunti, rimossi o sostituiti per rispondere alla domanda. È una differenza sostanziale. Un worker perso non dovrebbe imporre la ricostruzione di una copia autorevole completa: può ripartire e riscaldare la propria cache attingendo ai dati persistenti.

Anche compaction e garbage collection vengono spostate su worker separati, fuori dal percorso che deve rispondere alle operazioni degli utenti. Questo non elimina il lavoro di manutenzione; impedisce, quando possibile, che competa direttamente con le richieste che determinano la latenza percepita.

La ricostruzione di The Register del 9 ottobre conferma la direzione dell’intervento, ma non fornisce una data di completamento del rollout. Stiamo parlando di una transizione architetturale in corso, non di un risultato già distribuito uniformemente a ogni repository.

La coordinazione resta. Deve restare dove serve davvero

Separare storage e compute non autorizza a trattare Git come una collezione di file senza regole. Due agenti possono produrre oggetti indipendenti, ma quando entrambi vogliono aggiornare la stessa reference entra in gioco la consistenza. Un branch deve avere uno stato riconoscibile e le modifiche concorrenti non possono essere pubblicate fingendo che non esista conflitto.

Il principio illustrato da GitHub è ridurre la coordinazione al minimo indispensabile per rispettare la semantica del repository, lasciando procedere in parallelo il resto. Non è “eliminare i lock” o “rendere tutto eventual consistent”: sarebbe una scorciatoia concettuale, e probabilmente anche operativa. È distinguere le operazioni che richiedono un accordo comune da quelle che possono essere eseguite indipendentemente.

Questo ragionamento vale ben oltre Git. In un gestionale, per esempio, la generazione di un report e la conferma di un pagamento non richiedono lo stesso tipo di coordinazione. Se entrambe passano attraverso lo stesso collo di bottiglia solo perché condividono un database, il sistema sta facendo pagare a una lettura il costo di una garanzia che non le serve.

Il benchmark da 35 volte non è una promessa al tuo team

GitHub dichiara che la nuova architettura ha raggiunto fino a 35 volte il throughput di scrittura nei propri benchmark interni. È un risultato interessante e coerente con l’eliminazione di una parte della coordinazione superflua. Ma “fino a” non significa “sempre”, e un benchmark interno non equivale a una misura indipendente della produttività degli sviluppatori.

Anche se la push diventasse molto più veloce, resterebbero la coda della CI, la disponibilità degli ambienti di test, la qualità delle modifiche, i conflitti tra branch e la capacità di review. Accelerare una componente può semplicemente rendere più evidente il limite successivo. Chi ha lavorato su sistemi complessi lo sa: il collo di bottiglia non sparisce per gratitudine dopo un’ottimizzazione.

Per questo le metriche utili sono almeno di due tipi. Da una parte ci sono quelle infrastrutturali: latenza della push, throughput sostenibile, tempi di recovery, hit rate della cache e impatto delle operazioni di manutenzione. Dall’altra ci sono quelle del processo: tempo che passa tra una modifica proposta e una modifica verificata, integrata e realmente utilizzabile. Confondere le due cose produce presentazioni molto convincenti e sistemi non necessariamente migliori.

La lezione architetturale: separare responsabilità prima di moltiplicare risorse

La storia di Spokes è interessante proprio perché non descrive un sistema ingenuo. Cinque copie locali, quorum e protocollo di commit hanno sostenuto un servizio enorme per anni. Le scelte precedenti avevano una logica, e la nuova soluzione porta a sua volta complessità: cache da gestire, confini tra livelli, osservabilità e recupero dagli errori da verificare in produzione.

La domanda giusta, quindi, non è perché GitHub non abbia adottato prima l’architettura nuova. È quali assunti del carico originale non valgano più. Se le letture e le scritture crescono in proporzioni diverse, se un worker può essere sostituito senza perdere dati e se soltanto alcuni aggiornamenti richiedono consenso, continuare a far svolgere tutto allo stesso insieme di macchine diventa una scelta sempre più costosa.

È un criterio applicabile anche a progetti molto più piccoli: prima di aggiungere istanze, code, cache o server, chiedersi quale responsabilità stiamo effettivamente cercando di scalare e quale altra stiamo trascinando con noi senza motivo. A volte serve più capacità. Altre volte serve smettere di usare la stessa risorsa per lavori incompatibili.

Gli agenti AI rendono questa distinzione urgente, non perché abbiano inventato nuovi principi di informatica, ma perché producono carichi che non concedono più il lusso di nascondere certe inefficienze dietro i tempi umani. E forse questa è la notizia più interessante: la prossima generazione di strumenti di sviluppo non chiede soltanto modelli più veloci. Costringe a progettare meglio i sistemi che quei modelli attraversano.