So from a gut feeling that sounds right, finance is a pretty complicated domain with a lot of per vendor interactions, and Shopify outsources their payment stuff to Stripe.

Also on a headcount level, Google tells me Shopify has 3,500 employees to Stripe's 9,500. Obviously neither company is compromised entirely of engineers, so this is a ballpark estimate.

GitHub feels like the real case where there might be a larger codebase. It's in the middle for employees (6,500), but it's existed longer than Stripe (though not as much longer as my gut feeling told me, interestingly)

> Shopify outsources their payment stuff to Stripe

I thought they used active_merchant

The most recent publicly available numbers (that I know of, maybe there's a talk available somewhere that's more recent) are from https://stripe.com/blog/sorbet-stripes-type-checker-for-ruby

> currently amounting to over 15 million lines of code spread across 150,000 files

The monorepo has only gotten bigger over the last two years (source: I work at Stripe).

I should also note that number is Ruby files only.

I also wonder how they handle merge requests in a monorepo, especially when it comes to the code review process.

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.