Building Git infrastructure for agent-scale development

GitHub · 2026 · 4. Điều chỉnh · Độ khó: Khó — bài gốc

Bài định hướng, mở đầu series: nêu bài toán và nguyên tắc thiết kế; chi tiết kiến trúc mới hẹn ở bài sau. Số benchmark là nội bộ, theo GitHub.

Bối cảnh

• Tải tăng vọt vì agent (theo GitHub): tổng sự kiện Git từ 218,2 tỉ lên 473,3 tỉ mỗi tháng (9/2025 → 8/2026); push tăng 4,9 lần trong một năm (0,69 → 3,35 tỉ/tháng); 7,38 tỉ commit trong tháng 9/2026, gấp hơn năm lần năm trước; merge PR gần gấp 4; GitHub Actions 3,26 tỉ lần chạy trong tháng 9, gấp hơn 4. Phân bố rất lệch: repo bận nhất nhận khoảng một tỉ request trong tháng 8/2026.
• Các áp lực mới:
  • Agent commit sau gần mỗi hành động, nên thời gian một lần push thành giới hạn tốc độ của agent.
  • Hàng nghìn agent trên nhánh riêng trong một repo tạo tốc độ ghi đều đổ về một điểm của kiến trúc.
  • Trunk-based, release train, merge queue dồn mọi merge vào một ref.
  • Mỗi push nhân thành hàng nghìn lượt đọc (CI, code scanning fetch cùng tip nhánh hàng nghìn lần mỗi phút).
  • Việc nén và dọn dữ liệu repo tăng theo mỗi lần ghi.
• Kiến trúc hiện tại (Spokes): mỗi repo có bản đầy đủ trên đĩa cục bộ của nhiều fileserver (mặc định năm); cập nhật ref dùng three-phase commit theo quorum để CI, web, API thấy trạng thái nhất quán. Phục vụ tốt một tỉ repo.
• Giới hạn: cùng một cơ chế vừa lo độ bền vừa lo scale. Bản trên đĩa là nguồn sự thật, nên thêm năng lực đọc = thêm một bản sao bền, mà mọi bản sao đều tham gia mọi lần ghi; push chỉ nhanh bằng bản chậm nhất. Thêm replica để đỡ đọc làm ghi chậm đi; mất replica giảm năng lực đọc; mất quorum là dừng ghi.

Thay đổi chính (nguyên tắc thiết kế mới)

• Làm lại khi GitHub vẫn chạy, không có cửa sổ bảo trì, không đổi cách người dùng làm việc; giữ nguyên branch protection, review bắt buộc, audit log.
• Chỉ phối hợp phần cần đồng thuận: phần duy nhất của push thật sự cần đồng thuận là cập nhật ref; lưu object, kiểm tra kết nối object, quét secret nặng hơn nhiều nhưng phần lớn chạy song song với ghi khác. Đường găng của push co lại còn bước nhỏ đó.
• Đưa bảo trì ra khỏi đường phục vụ: nén và GC (hiện chạy trên chính máy phục vụ request Git) chuyển sang worker riêng làm trực tiếp trên storage bền.
• Tách storage khỏi compute: bản có thẩm quyền nằm trong Azure Blob Storage (độ bền và replication có sẵn); năng lực đọc đến từ worker nhẹ có cache, nên đỡ được spike đọc (CI fan-out, đội agent, clone lớn) mà không thêm việc cho mỗi push.
• Phục hồi nhanh hơn: mất một worker gần như một lần cache miss, worker mới phục vụ ngay và nạp cache dần, thay vì dựng lại cả bản sao repo.
• Capacity theo nhu cầu: thêm/bớt worker theo traffic thay vì cấp phát cho đỉnh; repo đang bùng nổ (release, đội agent mới) được thêm năng lực tạm.
• Benchmark nội bộ theo GitHub: thông lượng ghi cao tới 35 lần, đọc scale độc lập.

Vì sao

• Mô hình "mọi bản sao đầy đủ đều là nguồn sự thật và đều phục vụ đọc" ghép độ bền với scale; với tải ghi lớn và đọc fan-out lớn cùng lúc, hai mục tiêu kéo ngược nhau.

Bài học cho SWE

• Khi replica vừa để bền vừa để đọc, thêm replica làm ghi chậm đi: tách độ bền (storage) khỏi năng lực đọc (compute + cache) để scale từng bên (Failover, replica và dự phòng dữ liệu, Scale dọc trước khi scale ngang).
• Thu nhỏ đường găng cần đồng thuận xuống đúng phần cần (cập nhật ref), đẩy phần còn lại ra song song.
• Một ref nhận mọi merge là hot key của thời agent; phân bố tải giữa các repo cực kỳ lệch (Hot partition và thundering herd).
• Việc bảo trì nặng (nén, GC) không nên chạy trên máy phục vụ; cùng ý với PlanetScale chụp backup trên node riêng (PlanetScale 2026).
• Dùng object storage có sẵn làm lớp bền thay vì tự giữ N bản trên đĩa cục bộ là một lựa chọn kho dữ liệu theo workload (Chọn database theo workload).

Liên quan

• Tách compute khỏi storage
• Cùng công ty: GitHub 2021 · GitHub 2021 · GitHub 2026
• WarpStream 2026 (Kafka trên object storage, cùng hướng tách storage)
• Failover, replica và dự phòng dữ liệu · Hot partition và thundering herd · Scale dọc trước khi scale ngang · Chọn database theo workload