Every service boundary replaces a function call with a network request. That one choice cascades into distributed transactions, eventual consistency, and operational overhead most teams don't need. ¯\_(ツ)_/¯
That's the right approach. This is what the article suggests:
>> For most systems, well-structured modular monoliths (for most common applications, including startups) or SOA (enterprises) deliver comparable scalability and resilience as microservices, without the distributed complexity tax. Alternatively, you may also consider well-sized services (macroservices, or what Gartner proposed as miniservices) instead of tons of microservices.
>> Microservices make sense in very specific scenarios where distinct business capabilities need independent scaling and deployment. For example, payment processing (security-critical, rarely updated) differs fundamentally from recommendation engine (memory-intensive, constantly A/B tested). These components have different scaling patterns, deployment cycles, and risk profiles, which justify separate services.
Every service boundary replaces a function call with a network request. That one choice cascades into distributed transactions, eventual consistency, and operational overhead most teams don't need. ¯\_(ツ)_/¯