I can only attest to how Google does (did) it, but they use the monorepo as a serialized consistent history. There is no concept of deploying "the whole system" -- even deploying a single service requires, mechanically, multiple commits spread across time.
In fact, when I was last there in 2017, making a backwards-incompatible atomic change to multiple unrelated areas of the codebase was forbidden by policy and technical controls (the "components" system). You had to chop that thing up, and wait a day or two for the lower-level parts of it to work their way through to HEAD.
I would generalize this to say that the idea of deploying clients, schemas, backends, etc all at once is an inherently "small scale" approach.
Interesting, RE: Google. Though, even if no other large-scale company is doing this, it seems on face value to be an easier and safer way to develop software up to perhaps a medium scale system/problem (and assuming that you're not needing to make database changes). I've yet to see a benefit to straddling changes across multiple repositories...
The benefit of changes straddling repositories is having separation of control.
For example different npm (cargo, etc) packages are controlled by different entities. Semver is used to (loosely) account for compatibility issues and allow for rolling updates.
A single company requiring multiple repositories for control reasons might be an antipattern and might indicate issues with alignment/etc.
In fact, when I was last there in 2017, making a backwards-incompatible atomic change to multiple unrelated areas of the codebase was forbidden by policy and technical controls (the "components" system). You had to chop that thing up, and wait a day or two for the lower-level parts of it to work their way through to HEAD.
I would generalize this to say that the idea of deploying clients, schemas, backends, etc all at once is an inherently "small scale" approach.