Lonjakan lalu lintas data yang dipicu oleh otomatisasi agen kecerdasan buatan (AI coding agents) memaksa GitHub melakukan perombakan arsitektur penyimpanan dan jaringan terdalam dalam satu dekade terakhir. GitHub secara resmi mengumumkan telah berhasil menduplikasi salinan dari 99,99999 persen repositorinya ke infrastruktur cloud Microsoft Azure, sementara sisa 0,00001 persen repositori tersibuk di platform tersebut kini tengah disiapkan untuk migrasi penuh melalui transformasi radikal pada mekanisme konsensus Git.
Langkah ini menandai pergeseran besar dalam cara platform hosting kode terbesar di dunia tersebut mengelola keandalan data. Selama bertahun-tahun, infrastruktur Git GitHub bergantung pada kluster pusat data mandiri milik perusahaan. Namun, maraknya alat bantu pengembangan berbasis agen—mulai dari Copilot Workspace hingga agen otonom pihak ketiga yang terus-menerus membuat cabang, memicu build CI/CD, menguji integrasi, dan melakukan commit tanpa jeda—menciptakan pertumbuhan beban kerja eksponensial.
Menurut laporan tim rekayasa GitHub yang ditulis oleh Eleanor White dan Victoria Dye, percepatan migrasi ini didorong oleh kenyataan fisik di lapangan. Pusat data internal GitHub telah menyentuh batas plafon daya listrik regional (power capacity ceiling) yang tidak dapat diperluas lagi dalam waktu dekat, diperparah oleh keterbatasan pasokan fisik perangkat keras komputasi. Skala ekspansi data center konvensional tidak lagi mampu mengimbangi kurva pertumbuhan agen AI.
Sebagai solusinya, GitHub memulai pemindahan data ke wilayah Azure Central US sejak Agustus 2025. Saat ini, sebagian besar repositori di GitHub beroperasi dengan konfigurasi multiregion: dua dari lima replika data ditempatkan di Azure, sementara tiga replika lainnya tetap berada di pusat data mandiri GitHub. Pengaturan hibrida ini memungkinkan Azure menyerap sekitar separuh dari total lalu lintas Git global saat ini, sekaligus menstabilkan beban di pusat data internal.
Meskipun demikian, sisa 0,00001 persen repositori menghadapi kendala teknis yang jauh lebih rumit. Kumpulan kecil ini merupakan monorepo raksasa dan repositori publik paling aktif di dunia yang memiliki frekuensi penulisan (write throughput) sangat padat. Kendala utama migrasi repositori tersibuk ini bukanlah ukuran penyimpanan, melainkan jarak fisik sekitar 1.000 mil antara pusat data lama dan fasilitas Azure, yang menimbulkan latensi bolak-balik jaringan (round trip) sekitar 25 milidetik.
Dalam arsitektur konsensus tradisional GitHub yang dikelola oleh kluster Spokes, proses penulisan membutuhkan penguncian di tingkat keseluruhan repositori (repository-wide lock). Spokes memang hanya memerlukan suara mayoritas kuorum untuk mengonfirmasi penulisan, tetapi sistem tersebut dirancang untuk menunggu tanggapan dari setiap replika sehat hingga batas waktu tertentu agar replika tidak tertinggal. Akibatnya, replika yang paling lambat—dalam hal ini replika di Azure yang terpisah jarak 1.000 mil—menentukan latensi akhir dari setiap operasi penulisan. Ketika penulisan terus mengantre satu per satu di bawah penguncian repositori global, beban tinggi akan menyebabkan antrean membengkak dan memicu kegagalan transaksi push.
Untuk mengatasi kemacetan tersebut, tim rekayasa GitHub menerapkan prinsip desain pertama: meminimalkan koordinasi dengan cara tidak menyerialkan apa yang tidak perlu diserialkan. Dalam spesifikasi Git, jaminan konsistensi data sebetulnya hanya berlaku pada setiap referensi secara terpisah (per-reference)—seperti cabang tertentu, tag, atau referensi commit internal. Perubahan pada cabang fitur A tidak bergantung pada perubahan cabang fitur B.
GitHub mengubah cakupan kuorum dari tingkat repositori utuh menjadi kuorum berbasis referensi individual. Dengan per-reference serialization, agen AI maupun pengembang manusia yang melakukan push ke cabang berbeda tidak lagi saling mengunci atau menunggu. Hanya transaksi yang memodifikasi cabang yang sama yang perlu bersaing memperebutkan kunci konsensus. Dalam pengujian beban internal dengan profil lalu lintas nyata, pendekatan ini terbukti meningkatkan throughput penulisan antara 3 hingga 4 kali lipat pada tingkat latensi yang jauh lebih rendah.
Prinsip kedua dari arsitektur baru GitHub adalah memisahkan lapisan komputasi dari media penyimpanan (decoupling storage from compute). Sebagian besar repositori di GitHub memiliki beban kerja yang sangat condong ke pembacaan (read-skewed), dengan perbandingan berkisar antara 100 hingga 1.000 operasi baca untuk setiap satu operasi tulis. Pada sistem lama, operasi baca dan tulis bersaing memperebutkan sumber daya memori dan CPU pada mesin replika yang sama.
Dengan memindahkan penyimpanan data durabel ke Azure Blob Storage, GitHub memperkenalkan konsep replika virtual. Node komputasi efemeral pertama yang dikembangkan adalah "virtual write replica", yakni instans tanpa penyimpanan disk persisten yang bertindak sebagai jembatan ke Blob Storage. Node ini bergabung dalam kuorum penulisan, mengalirkan data baru ke penyimpanan objek, dan menggabungkan transaksi dari referensi-referensi yang terpisah ke dalam satu paket I/O jaringan efisien.
Di sisi pembacaan, GitHub kini dapat meluncurkan "virtual read replica" secara elastis sesuai lonjakan permintaan tanpa harus mendaftarkannya ke dalam kuorum penulisan. Replika baca ini memanaskan cache memori langsung dari Azure Blob Storage dan melayani permintaan pengembang atau bot penguji secara independen. Dalam pengujian stres terdistribusi, sistem pengujian internal GitHub bahkan mencapai batas kapasitasnya sendiri sebelum berhasil menemukan batas atas dari replika baca virtual tersebut.
Sistem Spokes yang kini memproses lebih dari 100 miliar operasi Git setiap hari akan tetap menjadi tulang punggung perutean dan penyeimbang beban, tetapi protokol commit di bawahnya telah beradaptasi agar mampu menopang generasi miliaran repositori berikutnya. GitHub dijadwalkan memaparkan wujud akhir arsitektur penyimpanan skala agen ini secara lengkap pada perhelatan GitHub Universe pada 28–29 Oktober 2026 di San Francisco.
Sumber tambahan: https://github.blog/engineering/architecture-optimization/building-git-infrastructure-for-agent-scale-development/