Uber SubmitQueue: a high-performance speculative merge queue • Hacker News Board

Re: Uber SubmitQueue: a high-performance speculative merge queue

#61

Post by fastball » Mon, Aug 10, 2026, 2:19 AM UTC

malfist wrote: post #58

fastball wrote: post #29

Earlier quoted context omitted.

Do you do any cross workspace/repo work, or are you mostly constrained to a single namespace?

Not op but I do cross repo work, but it's rightfully separate PRs as its separate services, separate contracts and separate deployments. Pretending a monorepo cross service PRs are contiguous is a recipe for deployment race conditions

Is it one or the other? You either need to keep everything in separate PRs or you need to pretend that services are contiguous where deployment order doesn't matter?

Re: Uber SubmitQueue: a high-performance speculative merge queue

#62

Post by mac-mc » Mon, Aug 10, 2026, 5:50 PM UTC

jedberg wrote: post #56

mac-mc wrote: post #53

Earlier quoted context omitted.

The big thing about monorepos in this case is making a change atomic across a set of projects. Multirepos can't do this 99% of the time and often add a lot more procedure to something close. It's inherently async.

> The big thing about monorepos in this case is making a change atomic across a set of projects. The thing microservices is supposed to solve is eliminating the need to make atomic changes across services. There is an inherent overhead in doing that, like making your service support both new and old APIs as long as any service exists using the old API. This is the cost of microservices.

The world isn't just backend. There are mobile projects, games, native desktop apps which act together as a suite and web frontends. Also microservices bring up their own host of issues and extra labor. Both are essentially the semantic versioning library update problem, and when you need to propagate a breaking change it create a whole bunch more labor that is significantly reduced in a monorepo vs. a multirepo/microservice world.

The tradeoff is you need to invest into repo scaling, much like a backend service that needs to invest in scaling itself too.

Re: Uber SubmitQueue: a high-performance speculative merge queue

#63

Post by fragmede » Mon, Aug 10, 2026, 6:49 PM UTC

kyrra wrote: post #38

fragmede wrote: post #22

Earlier quoted context omitted.

Why is that a problem? They sell Spanner on GCP. Sell Piper as well! It's obvious as shit but Google doesn't know what it's doing anymore. They should have bought GitHub, not Microsoft, and then we wouldn't have had the problems with scaling GitHub either.

Piper only works with CitC. Which is effectively a virtual file system when mounted locally. And when you have a monorepo that big, standard tools that want to scan an entire directory will stop working. Every part of the developer tool chain has to change to deal with code base that big. I agree that Google should have bought github. The tech they built to scale Google Code I think would have helped a ton with GitHu…

They sell and support Google Drive on Mac and windows, and the web. Selling a VFS layer is entirely within their capabilities. Blaze/Bazel has already been exported. You're right that there's a whole stack, but if Facebook can make jj happen, Google could make hg happen.