You have a single Java codebase in one repo to put all your code in. The code ultimately runs about 30 services/batch jobs (call these end points, or EPs). Some EPs share literally no code with others. All in all, we have well over 250 kloc compiled in one go to produce a single artefact (a jar, let's call it LEVIATHAN)
Each time a change is committed, the code is built and a new LEVIATHAN artefact version is emitted - hundreds of them, thousands even. There is a database where each EP is associated with the version of the code which should run it.
Stable EPs can thus be hundreds of versions behind current. Let's say that you need to update such a stable EP by adding some new feature. You are then in a position of having to bring EP "foobar" up from v1.2.3 of LEVIATHAN to v8.9.10. You have absolutely no idea whether code that Foobar depends on has changed problematically in this space.
I'm not in any way saying that this is a sensible way of organising a monorepo and I'm sure there are plenty of legitimat