Brian Celenza, kỹ sư phần mềm chính của GitHub, viết trên blog kỹ thuật chính thức ngày 6/10 rằng công ty đang xây lại tầng lưu trữ Git. Lý do được nêu thẳng: các AI agent đã đẩy lưu lượng ghi (write) vượt quá giới hạn của kiến trúc cũ. Trong các bài kiểm thử nội bộ, kiến trúc mới giúp thông lượng ghi tăng tối đa 35 lần.
Bài viết đưa ra một loạt số liệu tăng trưởng trong năm qua:
| Chỉ số | Số liệu mới nhất | So với năm trước |
|---|---|---|
| Sự kiện Git mỗi tháng | 473,3 tỷ (tháng 8/2026) | khoảng 2,2 lần |
| Push mỗi tháng | 3,35 tỷ | 4,9 lần |
| Commit mỗi tháng | 7,38 tỷ (tháng 9/2026) | hơn 5 lần |
| Lượt chạy Actions mỗi tháng | 3,26 tỷ (tháng 9/2026) | hơn 4 lần |
| PR được merge | không công bố số tuyệt đối | gần 4 lần |
Repo bận rộn nhất nhận khoảng 1 tỷ request chỉ trong tháng 8. Bài viết mô tả thói quen ghi của agent như sau:
"An agent in a tight loop commits or checkpoints after nearly every action" (Một agent chạy lặp liên tục sẽ commit hoặc tạo checkpoint sau gần như mỗi hành động.)
Kiến trúc cũ nghẽn ở khâu ghi
Hệ thống lưu trữ repo hiện tại của GitHub có tên Spokes. Theo mặc định, mỗi repo được lưu trọn vẹn trên ổ đĩa cục bộ của nhiều máy chủ file, tổng cộng 5 bản sao. Khi một lượt push cập nhật tham chiếu (ref), hệ thống dùng giao thức commit ba giai đoạn dựa trên đa số để đảm bảo CI, trang web và các client API đều thấy trạng thái repo nhất quán.
Trong thiết kế này, các bản sao đồng thời làm hai việc: chống mất dữ liệu và chia tải cho request đọc. Cái giá phải trả là mỗi bản sao đều phải tham gia vào từng lượt ghi — thêm bản sao giúp chịu được nhiều lượt đọc hơn, nhưng lại làm ghi chậm đi. Ở thời kỳ lập trình viên là người chủ đạo, lượt đọc nhiều hơn hẳn lượt ghi, nên sự đánh đổi này không vấn đề gì; nhưng khi agent kéo tần suất ghi lên cao, số lượng bản sao trở thành nút nghẽn của việc ghi.
Kiến trúc mới chia thành ba phần
Phần thứ nhất là giảm điều phối xuống mức tối thiểu: chỉ việc cập nhật tham chiếu mới cần các bên đồng thuận, còn lưu trữ object, kiểm tra tính hợp lệ, quét an ninh đều chuyển sang xử lý song song.
Phần thứ hai là tách lưu trữ khỏi tính toán. Việc lưu trữ bền giao cho Azure Blob Storage, còn request đọc do một nhóm worker nhẹ xử lý. Bài viết nói:
"Separating the two lets us scale each one independently" (Tách hai phần này ra giúp mở rộng từng phần một cách độc lập.)
Phần thứ ba là tách riêng việc bảo trì nền: nén dữ liệu và thu gom rác chạy trên worker riêng, không còn tranh tài nguyên với request thời gian thực. Các cơ chế kiểm soát như bảo vệ nhánh, bắt buộc review, nhật ký kiểm toán và khả năng quan sát đều được giữ nguyên.
Thử tính nhanh bài toán ghi
Tính thô theo tháng 30 ngày, 7,38 tỷ commit tương đương khoảng 2.850 lượt/giây; 3,35 tỷ push tương đương khoảng 1.290 lượt/giây, so với khoảng 270 lượt/giây một năm trước. Nếu mỗi lượt push cần cả 5 bản sao tham gia, kiến trúc cũ phải xử lý khoảng 6.500 lượt ghi bản sao mỗi giây (số ước tính, chưa tính retry và tác vụ bảo trì).
Mức tăng thông lượng 35 lần tương ứng với tốc độ tăng push theo năm là 4,9 lần, trên giấy tờ để lại dư địa vài năm. Điều kiện là đường tăng trưởng của lưu lượng agent không tiếp tục dốc lên, và chính GitHub cũng không đưa ra dự báo cho việc này.
Những gì bài viết không nói tới
Bài viết không đưa ra mốc thời gian cho việc kiến trúc mới đã di chuyển bao nhiêu repo hay khi nào chuyển đổi toàn bộ; cũng không nói rõ benchmark 35 lần được đo trên repo cỡ nào, mức độ đồng thời ra sao. Những ảnh hưởng có thể có với người dùng, chẳng hạn giới hạn tốc độ có điều chỉnh hay không, cũng không được đề cập.
Năm nay GitHub từng có vài lần gián đoạn dịch vụ kéo dài, bài viết này không phản hồi về các sự cố đó, cũng không nói kiến trúc mới có tránh được tình trạng tương tự hay không. Celenza hẹn ở cuối bài rằng phần tiếp theo trong series sẽ nói kỹ hơn về kiến trúc tương lai và bối cảnh của lần cải tổ này.
Nguồn tham khảo: blog kỹ thuật của GitHub, CocoLoop; số liệu chính thức của GitHub được dùng để đối chiếu cách tính commit, push và lượt chạy Actions theo tháng.