Your Monorepo's Merge Queue Has a Concurrency Problem

A concurrency issue in monorepo merge queues often creates bottlenecks, as serial processing forces teams to wait unnecessarily for their CI pipelines to complete. This problem arises because traditional merge queues operate like linked lists, making every pull request (PR) wait for the preceding one to pass CI, regardless of whether they share dependencies or not. By transitioning from a serial list to a directed acyclic graph (DAG) model using scopes, teams can independently run CI for PRs that do not conflict, thereby reducing wait times significantly. Scopes, determined through file path patterns or monorepo tools like Nx and Bazel, allow the queue to understand which parts of the codebase each PR affects, enabling concurrent CI runs based on these dependencies. This parallel mode not only speeds up the process by allowing independent PRs to run simultaneously but also isolates failures to their specific scopes, ensuring unaffected PRs continue without interruption. While this system is particularly advantageous for teams with clear project boundaries, it also provides partial benefits even when some code dependencies overlap, making it a more efficient alternative for handling CI pipelines in monorepos.