Datadog ha presentado gitretriever, una capa de espejado de Git diseñada a medida para alimentar su infraestructura de integración continua. En los cuatro primeros meses en producción, el sistema atendió más de mil millones de peticiones de Git y varios cientos de terabytes de código, y hoy supera los cien millones de solicitudes semanales. Pese a multiplicar por veinte el tráfico desde su lanzamiento, la latencia mediana se ha mantenido en torno a 40 milisegundos, mientras que el consumo de CPU del backend de fetches se ha reducido entre tres y cuatro veces.
El problema de partida era el cuello de botella que GitLab, montado sobre Gitaly y Praefect y sincronizado con GitHub mediante un servicio interno llamado codesync, no podía resolver por más nodos que se añadieran. En una arquitectura replicada, los costes de escritura crecen con cada réplica, así que aumentar capacidad solo incrementaba la sobrecarga de replicación. Una CDN no servía porque la parte costosa de un fetch no es un rango de bytes cacheable, sino la construcción del packfile de respuesta, específica de cada cliente. Y clonar desde GitHub trasladaba el problema aguas arriba, chocando con los límites de tasa del servicio.
La solución adoptada se basa en pods independientes que mantienen su propia copia local de los repositorios y la sirven directamente, sin consenso entre pares ni replicación multi-escritor. Cada pod se sincroniza con GitHub y responde a las peticiones desde su copia, eliminando la concentración de CPU en unos pocos nodos. Los ingenieros describen también el motivo por el que un fetch de Git es caro: la negociación del protocolo v2 y, sobre todo, la construcción del packfile de respuesta, con objetos descomprimidos y recomprimidos mediante deltas, saturan CPU y almacenamiento bajo cargas concurrentes elevadas. El artículo detalla los tipos de datos de Git (blobs, trees, commits y referencias), el funcionamiento del protocolo v2 y las estrategias de optimización que el equipo probó antes de optar por el nuevo diseño.