Independent deployment. Shipping a fix to the Payments service doesn't require redeploying (or even retesting) Orders and Users — a monolith's single deployable unit means any change, however small, needs the whole application rebuilt, retested, and redeployed.
Independent scaling. If Orders gets 100x the traffic of Users, you scale only that service's infrastructure, rather than scaling an entire monolith (including the parts that didn't need it) just to keep up with one hot path.
Team autonomy. Different teams can own different services, choose their own release cadence, and even their own tech stack per service — a team that would benefit from a different language or database for their specific problem isn't blocked by the rest of the organization's stack.
Fault isolation, in principle. A crash or resource exhaustion in one service doesn't necessarily take down others, the way an unhandled exception or memory leak in a monolith can bring down the entire application (every feature runs in the same process). This benefit is conditional, not automatic — see the resilience patterns section below for what's actually required to realize it in practice.