Brian Celenza, principal software engineer di GitHub, menulis di blog teknik resmi perusahaan pada 6 Oktober bahwa GitHub sedang membangun ulang lapisan penyimpanan Git-nya. Alasannya ditulis blak-blakan: agen AI mendorong trafik penulisan hingga melampaui batas arsitektur lama. Dalam benchmark internal, arsitektur baru ini meningkatkan throughput penulisan hingga 35 kali lipat.
Tulisan tersebut memberikan sejumlah angka pertumbuhan selama setahun terakhir:
| Metrik | Angka terbaru | Year-over-year |
|---|---|---|
| Event Git bulanan | 473,3 miliar (Agustus 2026) | sekitar 2,2x |
| Push bulanan | 3,35 miliar | 4,9x |
| Commit bulanan | 7,38 miliar (September 2026) | lebih dari 5x |
| Jalankan Actions bulanan | 3,26 miliar (September 2026) | lebih dari 4x |
| PR yang di-merge | angka absolut tidak diberikan | hampir 4x |
Repositori tersibuk menerima sekitar satu miliar permintaan hanya dalam bulan Agustus. Tulisan itu menggambarkan kebiasaan penulisan agen seperti ini:
"An agent in a tight loop commits or checkpoints after nearly every action"
(Agen yang berjalan dalam loop ketat melakukan commit atau checkpoint hampir setiap kali menjalankan satu aksi.)
Arsitektur lama terhenti di titik penulisan
Sistem penyimpanan repositori GitHub yang ada disebut Spokes. Secara default, setiap repositori disalin penuh ke disk lokal beberapa file server, total lima salinan. Saat push memperbarui referensi, sistem menggunakan protokol three-phase commit berbasis mayoritas untuk memastikan CI, situs web, dan klien API melihat status repositori yang konsisten.
Dalam desain ini, setiap replika menjalankan dua tugas sekaligus: mencegah kehilangan data, dan menyerap trafik baca. Konsekuensinya, setiap replika harus ikut serta di setiap penulisan, sehingga menambah replika untuk menangani lebih banyak pembacaan justru memperlambat penulisan. Trade-off ini tidak menjadi masalah di era saat pengembang manusia mendominasi dan pembacaan jauh lebih banyak daripada penulisan. Begitu agen mendorong naik frekuensi penulisan, jumlah replika itu sendiri menjadi bottleneck penulisan.
Arsitektur baru dipecah jadi tiga bagian
Bagian pertama adalah meminimalkan koordinasi: hanya pembaruan referensi yang masih membutuhkan kesepakatan antar-pihak; object storage, validasi, dan pemindaian keamanan sekarang berjalan paralel.
Bagian kedua adalah memisahkan storage dari compute. Persistensi diserahkan ke Azure Blob Storage, sementara permintaan baca ditangani sekumpulan worker process yang ringan. Seperti disebutkan dalam tulisan tersebut:
"Separating the two lets us scale each one independently"
(Memisahkan keduanya membuat kami bisa men-scale masing-masing secara independen.)
Bagian ketiga memisahkan pemeliharaan di belakang layar: compaction dan garbage collection kini berjalan di worker process tersendiri, tidak lagi bersaing sumber daya dengan permintaan real-time. Perlindungan branch, review wajib, log audit, dan kontrol observability semuanya tetap dipertahankan.
Hitungan kasar beban penulisan
Dengan asumsi satu bulan sama dengan 30 hari, 7,38 miliar commit bulanan setara dengan sekitar 2.850 per detik; 3,35 miliar push bulanan setara dengan sekitar 1.290 per detik, naik dari sekitar 270 setahun lalu. Jika setiap push masih membutuhkan partisipasi lima replika, arsitektur lama harus menangani sekitar 6.500 penulisan replika per detik (perkiraan kasar yang belum memperhitungkan retry dan tugas pemeliharaan).
Peningkatan throughput 35x dibandingkan laju pertumbuhan push tahunan 4,9x secara perhitungan menyisakan ruang beberapa tahun ke depan — dengan asumsi kurva pertumbuhan trafik agen tidak makin tajam, sesuatu yang bahkan GitHub sendiri tidak berani memperkirakan.
Yang tidak dijelaskan dalam tulisan ini
Tulisan ini tidak memberikan linimasa soal berapa banyak repositori yang sudah bermigrasi ke arsitektur baru atau kapan transisi penuh akan terjadi, dan juga tidak menjelaskan skala repositori atau tingkat concurrency yang digunakan dalam benchmark 35x tersebut. Dampak potensial bagi pengguna, misalnya apakah rate limit akan disesuaikan, juga tidak disinggung.
GitHub mengalami beberapa gangguan layanan berkepanjangan tahun ini, tetapi tulisan ini tidak membahas insiden-insiden tersebut maupun apakah arsitektur baru bisa mencegah hal serupa terjadi lagi. Celenza menutup tulisannya dengan memberi bocoran bahwa tulisan selanjutnya dalam seri ini akan membahas lebih dalam arsitektur masa depan serta latar belakang perombakan kali ini.
Sumber: Blog Teknik Resmi GitHub, CocoLoop; angka commit, push, dan Actions run bulanan diverifikasi berdasarkan data resmi GitHub.