Thanks for sharing, Filip!
We’re using a somewhat similar approach at my company — but we also allow ourselves some things that I’d imagine be hard when run on “Google scale”.
We also have a single repo for all our components & configuration & infrastructure-as-code. However, we follow a modified Github-Flow approach, where PRs are made off feature branches (and long-running branches, too, when not avoidable), where the entire infra is brought up and tested against the changes of the branch (and automatically discarded in the end.)
I do find that if our org were to grow much, we would benefit from splitting off and versioning our services — however we would of course lose the ability to do lateral changes. Would you agree or still think that keeping the code in one repo is still the golden standard with a large codebase and many committers?
Also, how do you deal with the problem of the “moving tip” of the repo? You mentioned many dependencies — what if there are simultaneous commits that touch same areas of code? (I’d imagine it happening quite often with 16k commits per day). Is it a source of anxiety and frustration for your developers?