You are oblivious to the point of this approach. Scaling has nothing to do with it. It has everything to do with not imposing useless and detrimental constraints that buys you nothing but problems. You specify interfaces, and keep implementation details from leaking by encapsulating and insulating them. This is terribly basic stuff.

It'd be great if you minded your tone; this is HN.

I don't know where you're getting implementation details leaking when it's just API definitions being shared - they don't leak implementation details unless they're badly designed, which would affect them either way.

You can do all that without separate services.

OOP languages have interfaces.

You can do this already without adding any sort of microservice, schemas, duplicate definition files, externally maintained libraries, etc..

It's a basic feature of most languages.

It is NOT an exclusive benefit of a microservice pattern. Stop claiming that, it's one of the most frustrating claims/lies microservice advocates make.

The actual benefit is that you're forcing developer to use interfaces. At a massive cost.

There are much cheaper alternatives. You enforce a Dependeny Injection pattern on your services. Code reviews. Linting tools.

So no, this is not basic stuff.

And worse still, if your team can't properly use interfaces in your languages, how do you expect them to suddenly learn to use them properly in your services?