GitHub представил новую архитектуру хранения Git Project Rubicon, рассчитанную на рост параллельной работы AI-агентов. Во внутреннем тесте 5000 агентов одновременно работали с одним репозиторием и выполняли 7200 push в секунду, а чтение сохраняло стабильно низкую задержку. Сейчас самые загруженные репозитории GitHub.com получают лишь десятки записей в секунду короткими всплесками; компания проектирует систему с запасом минимум на два порядка.
Основной принцип — согласовывать только обновления ссылок. Git-объекты неизменяемы и адресуются содержимым, поэтому разные писатели могут сохранять их параллельно. Packs и вспомогательные данные размещаются в Azure Blob Storage. Ссылки и manifest паков находятся в отдельном реплицированном журнале Ref-CAS, который выполняет compare-and-swap через кворум и блокирует только затронутые ссылки.
Запросы по-прежнему проходят через Spokes, отвечающий за маршрутизацию, балансировку и изоляцию tenant. Трафик репозитория обслуживает небольшая группа виртуальных реплик — одноразовых вычислительных узлов с локальным кешем. Для записи реплика индексирует pack, загружает его в Blob Storage и лишь затем одной транзакцией обновляет manifest и ссылки в Ref-CAS. Так ссылка никогда не указывает на ещё не сохранённые объекты.
При чтении реплика сообщает Ref-CAS известную версию ссылок. Если она актуальна, ответ ограничивается одним сравнением; иначе реплика получает новые ссылки и указатели на нужные packs. Вычислительные узлы можно добавлять независимо от хранения, а отказ одного не влияет на корректность работы остальных.
Прототипы на условных записях в один blob давали только несколько сотен записей в секунду. Разбиение на сегменты повышало предел записи, но замедляло чтение, которого на порядки больше. Ref-CAS устраняет этот компромисс: независимые ссылки реплицируются параллельно, а при конфликте на одной ссылке успешен только один push.
Compaction и garbage collection вынесены на отдельные узлы. Они работают с shards по lease, объединяют packs и проверяют сохранность объектов до публикации. Это удерживает количество packs и задержку почти постоянными при росте записей. Архитектура доступна в ограниченном private preview, более широкий запуск ожидается в начале следующего года. Дальше GitHub планирует чтение отдельных объектов, частичные реплики, работу агентов без clone, атомарный commit API и event streams.