GitHub ha pubblicato sul proprio blog tecnico i dettagli di una profonda revisione dell’API che espone la cronologia delle star dei repository. Il problema di partenza era l’elevato numero di richieste necessarie per ricostruire l’andamento temporale delle star: il sistema precedente doveva recuperare l’elenco completo degli stargazer per ogni repository, operazione che poteva richiedere fino a 2.500 chiamate API per i progetti più popolari. Questo approccio generava un carico significativo sul database e sollevava questioni di privacy, poiché esponeva le identità degli utenti che avevano messo la star.
La nuova architettura, descritta nell’articolo “From 2,500 requests to 24: Rebuilding star history without the stargazers” pubblicato il 14 ottobre 2026, adotta una strategia basata su dati pre-aggregati. Invece di interrogare la tabella degli stargazer a ogni richiesta, il sistema mantiene contatori giornalieri aggiornati in modo asincrono. Quando un utente mette una star, un processo in background incrementa il contatore del giorno corrispondente per quel repository. L’API pubblica restituisce quindi direttamente queste serie temporali aggregate, riducendo il numero di richieste necessarie a 24 per repository (una per ogni giorno degli ultimi 24 giorni, o un numero fisso di bucket temporali).
I vantaggi sono molteplici. Dal punto di vista delle prestazioni, il carico sul database primario diminuisce drasticamente perché le letture non devono più scansionare milioni di righe della tabella degli stargazer. La latenza dell’API migliora di conseguenza, offrendo risposte quasi istantanee. Sul fronte della privacy, l’endpoint non restituisce più alcun identificativo utente: i consumatori dell’API ricevono solo conteggi giornalieri, impedendo qualsiasi forma di deanonimizzazione o analisi comportamentale sugli stargazer individuali.
Tuttavia, i tecnici di GitHub evidenziano anche i compromessi accettati. L’aggregazione introduce una granularità temporale fissa (giornaliera) e una leggera ritardo nella propagazione dei dati, poiché i contatori vengono aggiornati tramite job asincroni. Inoltre, la rimozione degli identificativi impedisce funzionalità avanzate come la visualizzazione degli stargazer più recenti o l’analisi di coorti, che ora richiederebbero endpoint separati e controllati. La scelta riflette una priorità chiara: ottimizzare per il caso d’uso prevalente — la visualizzazione di trend storici — sacrificando flessibilità secondarie.
L’implementazione ha richiesto modifiche allo schema del database, l’introduzione di tabelle di aggregazione e la riscrittura del layer API con nuovi endpoint versionati. Il team ha adottato un rollout graduale, mantenendo la compatibilità con la vecchia API durante la transizione. I test di carico hanno confermato una riduzione dell’utilizzo CPU del database superiore al 90% per questo carico di lavoro.
Questa evoluzione si inserisce in un più ampio sforzo di GitHub per rendere le proprie API più scalabili e rispettose della privacy, seguendo principi di data minimization. L’approccio basato su aggregazioni precalcolate potrebbe essere esteso ad altre metriche pubbliche come fork, watcher o contributi, dove l’identità individuale non è strettamente necessaria per la maggior parte delle visualizzazioni aggregate.