When the time comes, cleave these chunks off and wrap them in RPC/REST/graphql.
It's good form even for monoliths since it makes for an easy interface to test.
I guess the trick when building new monoliths is to identify these fault lines up front - as opposed to hopefully finding them later.
Will certainly guide my development going forward, thanks.
So basically some monoliths playing together.
I've always been admiring that design and how much it could do and handle with so little resources.
Most times for a whole editorial newsroom a single 48c/128gb machine can be more than enough.
They were particularly smart on avoiding relational databases and sticking to an object database (Versant oodbms, another mostly unknown marvel of software engineering).
That software, even with its shortcomings, was really a great piece of software engineering.
If you can get away with a monolith, it's the way to go, as long as you leave room to quickly grow horizontally as well, if needed.
That depends on what kind of service you offer, of course.
This is really important wisdom being shared.
And with a single monolith you can comfortably handle several thousand concurrent users, not just several hundred.
From my humble experience I've found that it is also relatively easier to migrate an established monolith to a semi-distributed system, than it is to build and scale a distributed system from the ground up whilst at the same time trying to figure out all its kinks before it too becomes an established system.