How do you keep an affected-detection CI pipeline fast and reliable as a monorepo grows into the thousands of projects — what specifically starts to break, and what strategies address it?

## What starts to strain Affected detection is designed to make CI cost scale with change size rather than repo size, but at genuinely large scale — thousands of projects, hundreds of engineers committing continuously — several assumptions that held comfortably at hundreds of projects start to strain, and the mitigations become a distinct engineering discipline in their own right. ## The cost of affected computation itself The first strain point is the cost of affected computation itself. Building or loading the full project dependency graph, then running the reverse-dependency traversal, is not free — at thousands of nodes with dense edges, naive re-parsing of every project's manifest/imports on every CI invocation becomes a meaningful fraction of total pipeline latency. The standard response is to make the graph itself an **incrementally-maintained artifact**: cache the parsed graph, and on each run only re-parse the subset of projects whose manifests changed, patching the cached graph rather than rebuilding it from scratch. Nx's daemon process and cached project graph, and Bazel's persistent analysis cache, both exist substantially to amortize this cost across runs rather than paying full graph-construction cost every time. ## High-fan-in nodes become the bottleneck The second strain point is structural: at scale, dependency graphs in real organizations are rarely uniform — they typically have a small number of extremely **high-fan-in nodes** that a large fraction of all other projects transitively depend on: - shared UI component libraries, - core data models, - authentication SDKs. Because affected detection's reverse-traversal naturally funnels almost every meaningfully-sized change through these nodes, they become de facto critical-path bottlenecks on a huge fraction of CI runs, not just occasionally. The response isn't a build-scoping technique per se but an organizational one: treat build/test speed of these specific high-fan-in projects as a first-class investment, because every second shaved off their task duration multiplies across nearly every affected run in the whole repo, whereas the same investment in a leaf project only helps that project's own runs. ## Distributing the task execution The third strain point is distributing the actual task execution. A single CI machine's core count stops being enough well before a monorepo reaches thousands of projects with meaningful PR velocity, so task execution has to fan out across a worker fleet — via a remote-execution protocol (Bazel's remote execution API) or a distributed-task-orchestration layer (Nx Cloud-style agents, or custom sharding on top of a CI provider's matrix-job primitive). At this point, naive work distribution (round-robin, or splitting tasks evenly by count) performs poorly, because task durations vary wildly — a few large integration-test targets can dominate wall-clock time even if they're a small fraction of the task count. Production-grade schedulers instead **bin-pack tasks across workers using historical duration data** collected from prior runs, aiming to equalize total predicted time per worker rather than task count per worker, which is what actually shortens the long pole. ## Paying for the safety net The fourth strain point is the periodic full-suite safety net itself. Since affected detection accepts some false-negative risk in exchange for speed, most large-scale operations keep an exhaustive nightly or pre-release run as a backstop — but at thousands of projects, even that exhaustive run becomes expensive enough to need its own scaling strategy: - sharding it across many machines just like a normal CI run; - or staggering different portions of the full suite across different nights rather than running literally everything every night, accepting a longer detection window for the rarest false-negative classes in exchange for keeping the safety-net's own cost bounded. ## Merge queues at high velocity Finally, at high commit velocity, merge queues introduce a subtler correctness dimension: affected detection computed per-PR in isolation can miss interaction effects between two changes landing close together, each individually 'affected-clean' but combined causing a break neither change's isolated affected set would have caught. Mature merge-queue implementations address this by re-running affected checks against the queue's actual merge order (each change tested against the tip that includes everything ahead of it in the queue, not against its original branch point), rather than trusting each PR's isolated affected computation as sufficient once several changes are landing concurrently. This is less about the build-scoping mechanism itself and more about correctly sequencing when and against what base each affected computation runs — but at scale, getting that sequencing wrong is a common source of 'green in the queue, broken after merge' incidents distinct from the dependency-graph-completeness failures discussed elsewhere.