I don't think that microservices work well with a pure server kind of architecture. For one you miss out on a fundamental microservice advantages, scalability and portability.
If you have a system with 100 well-defined modules, but blue-widget-model is throwing errors, you know which codebase you need to look at.
No modularization technique has a monopoly on this characteristic.
For example, if you're working in Java 8 where everything's just one big jumbled globally visible classpath, sure. If, on the other hand, you're working in Java 9 or later, you have the ability to control your public interface. People can get around that with reflection, so it's technically more permeable than a service boundary, but, if you're letting shenanigans like that sail past code review, you get what you deserve.
That and a few other details make the feature annoying enough to use in practice that most people just find it's better to just stop using it.
Fortunately, if you're on Java 9 or later, there are modules, which are a much better fit for what kinds of access control tooling programmers actually need.
A monolith can be quite scalable and portable.
monolith --start-batch-jobs
monolith --start-claim-processor
monolith --start-graphql
Need scale?
k8s replica count on the above pods.
By going down a microservice route, those boundaries are ruthlessly enforce because it's the only way. That trade off may or may not be worth it.
There is an in-between that you can aim for.