I believe the "right" way to do it is to have every repo only able to talk to another repo's code via versioned APIs. So e.g. a client repo can ship an update t

I believe the "right" way to do it is to have every repo only able to talk to another repo's code via versioned APIs. So e.g. a client repo can ship an update that will talk to some service repo's code at either version N or N+1, the server repo can later on leisurely ship its update that actually makes version N+1 available (and has to support however many prior versions by policy). Or vice-versa, the server side can have N and N+1 already in service while the clients roll out their updates. You have to do something like this anyway if you have a mobile app. Of course it has consequences and makes some things harder, you really have to go in on API-first even for things like UI widgets if different ones live in different repos, but it at least alleviates the common problem of trying to get multiple repo commits merged at the same time and have everything keep agreeing. I still prefer the monorepo approach.