A median of 40 ms across more than 100 million weekly requests is a statement about the request mix [5][6]. Datadog puts one fetch from a large monorepo at several seconds of server CPU [12]. To finish several seconds of CPU work inside 40 ms of wall clock, you would need on the order of 75 cores on that single request [3]. The median, then, describes the fleet staying responsive while the heavy requests ran underneath it, which is the right thing to measure for a mirror, and the wrong number to plan a monorepo clone budget around.
Twentyfold growth to more than 100 million requests a week puts launch near 5 million a week [1]. The first four months carried more than a billion requests [4], about 58 million a week over roughly 17 weeks, which sits above the 52.5 million midpoint between those two endpoints [2]. The load did not arrive gently at the end.
The three-to-fourfold CPU reduction is reported on the previous backend [7], the Gitaly cluster behind Praefect that CI fetched from directly [8]. That measures work leaving the tier that was failing. What gitretriever spends to serve the same fetch is a separate number, and it is the one that decides whether this is efficiency or relocation.
Datadog's replicated setup copied every write to every replica, so each node added to serve reads added replication work [14]. Reads scale with CI job count; writes scale with replica count [17]. Adding nodes to a system where every write lands on every node is a capacity plan with a sign error. Peaks landed as hundreds of simultaneous fetches on the same handful of nodes, and more nodes sometimes made per-node CPU worse [13].
A CDN or caching proxy has nothing to hold, because the expensive part of a fetch is computation specific to each client's request rather than a static byte range [15]; Git's objects are immutable and content-addressed while references are mutable names stored separately [18]. Cloning on demand from GitHub relocates the herd to an upstream with server-side rate limits [16]. Both obvious escapes fail for the same structural reason: neither changes what actually costs the CPU.
For these numbers to transfer, several things have to be true of your setup. Your authoritative remote has to be separate from the one CI reads, as GitHub and self-hosted GitLab are here [8]. Read volume has to track job count, not headcount [17]. Your repositories have to be dense enough that a single fetch costs seconds of CPU, which for Datadog means monorepos with years of history and hundreds of thousands of files [2][12]. If your Git server is one node, or a replica set that does not fan writes out to every member, the constraint that forced this design is not your constraint.
Senior staff engineer Mike Thompson and staff engineer Daniel Esponda attribute the order-of-magnitude traffic jump to AI coding agents, which they say hit Git harder and more often than Datadog's most active human contributors ever did [9][19]. If that is the driver, Git capacity stops tracking contributor count and starts tracking agent concurrency, and the fetch path is a thing you size deliberately before it turns into multi-hour CI outages [10].
