It's very clearly implied in the "A modern entitlement/billing architecture" section:

> The requests should go to the entitlement system

> You may be thinking “isn’t this causing a single point of failure?” – and yeah, you’re right.

> In case the entitlement system (or a downstream system) fails, you should have some sane defaults.

Talking about an entitlement "service", not a term I see used for "another part of the same code base", talking about it being a new single point of failure, the seeming mapping out of a JSON API.

Service classes are a common pattern used in monolithic codebases to isolate related logic from the rest of the system. Everything the author described in the article can absolutely be built in a monolithic codebase sharing the same database, or separate databases if you prefer.

> Service classes are a common pattern used in monolithic codebases to isolate related logic from the rest of the system.

Yes, we have them in our code base. I'm pretty much 100% sure the author wasn't referring to these though, the way the author refers to "the service" is not how I've seen people refer to service classes.

> Everything the author described in the article can absolutely be built in a monolithic codebase sharing the same database, or separate databases if you prefer.

Yes, that, and the fact that the author seemed to assume that a microservice would be involved was what made me comment.