The core of microservice approach contains two ideas:

• narrow business domains
• small and independent teams (2-pizza team size)

So, splitting monoliths into microservices immediately brings benefits:

• smaller codebases — easier to comprehend, faster to change
• higher cohesion — easier to comprehend, more reasonable to scale when needed
• smaller build sizes — cheaper infrastructure and better horizontal scaling

These benefits are balanced by fundamental trade-offs:

• the system becomes distributed — network delays and partitions become ordinary and must be designed for
• the system becomes asynchronous — integration and end-to-end testing becomes significantly harder
• events are now processed by service chains — bugs become harder to trace, reproduce, and reason about
• wrong service boundaries are expensive — errors here lead to numerous inter-service dependencies, spawning a “distributed monolith”, combining cons of both approaches while bringing few benefits

Microservices shift complexity from code size to communication structure, forcing boundaries between business logic and supporting infrastructure.