It's possible to get stuck in merge hell where all your reviewers ok the PR but someone merged a conflict 2 seconds ago, or you've got a reviewer in Singapore while you're in SF and conflicts appeared overnight.

In general it was pretty rare, in my experience. The code bases were pretty well modularized.

Typically you have owner files or similar in the subprojects that are read by automation tooling and humans alike

Hi! I work at Stripe on this. What're you curious about?

When you are working on a large monolith, how exactly do you managed pull request?

Are they split into git-sub modules/ frameworks? Curious to know the development code review flow.

PR's are not split into submodules/frameworks for distinct review purposes. Functionally though, right now we have three distinct monorepos (not very 'mono' but we're working on it!), that represent our three main development stacks.

In our PR tooling, there's nothing that enforces/encourages scoping changes to a specific subset of any given repo. We generally encourage smaller PRs as a best practice, but a huge chunk of the benefit of a moonorepo is folks can make cross-cutting changes if/when necessary.

We have some custom goo on top of Github that manages the review flow. Specifically, we try to make it easy for folks to farm out reviews to the teams that own the code you're editing, so they don't have to hop in Slack and track down reviewers.