Just use a monorepo
IMO the biggest drawback to a monolith, maybe beyond those listed, is losing the 1-1 mapping of changes to CI to releases. If you know &quot;this thing is broken&quot;, the commit log is a fantastic resource to figure out what changed which may have broke it. You submit a PR, and CI has to run; getting most CI platforms cleanly configured to, say, &quot;only run the user-service tests if only the user-service changes&quot; isn&#x27;t straightforward. I understand there are some tools (Bazel?) which can do it, but the vast, vast majority of systems won&#x27;t near-out-of-the-box, and will require messy pipelines and shell scripts to get rolling.<p>There&#x27;s also challenges with local dev tooling. Many VSCode language extensions, for example, won&#x27;t operate at their best if the &quot;language signaler&quot; file (e.g. package.json for JS) isn&#x27;t in the root of the repo; from just refusing to function, to intellisensing code in another project into this one, all manner of oddities.<p>Meanwhile; I don&#x27;t think the purported advantages are all that interesting. Being able to write the blog post and make the change in the same PR? I&#x27;ve never been in a role where we&#x27;d actually want that; we want the change running silently in prod, publish the blog post, flip a feature flag or A&#x2F;B test proportions. Even an argument like &quot;you can add schemas and the API changes in one go&quot;; you can do that without a &quot;monorepo&quot;, just co-locate your schemas with the API itself, this isn&#x27;t controversial or weird, this is how everywhere I&#x27;ve worked operates.<p>None of that is to even approach the scale challenges that come with monorepos at even reasonable sizes; which you can hit pretty quickly if you&#x27;re, say, vendoring dependencies. Trying to debug something while the Github or Bitbucket UI is falling over because the repo is too large, or the file list is too long, isn&#x27;t fun.<p>I&#x27;m not going to assert this is a hill I would die on, but I&#x27;m pretty staunchly in the &quot;one service, for one deployment artifact, for one CI pipeline, for one repo&quot; camp.