Independent Deployability
The property that a service can be released to production without coordinated release of any other, which is the defining benefit of microservices.
This is the benefit microservices exist to deliver. Independent scaling, technology choice and fault isolation are real but secondary — and each is achievable by other means. If services cannot be deployed independently, the architecture is providing distribution costs with no return.
What it actually requires, and each of these is routinely missing:
Backward-compatible interfaces, so a new version works with old callers. This means additive changes only, versioning where a break is unavoidable, and contract testing in CI to prove it.
No shared database. A schema written by several services is an undocumented public contract that nobody can change alone.
Separate deployment pipelines, so a release is not gated by another team's readiness.
Independent data ownership, with cross-service data obtained via API or events rather than by reaching into another service's store.
Tolerance of version skew, since during any rollout multiple versions run simultaneously.
The diagnostic question is simply: can this service be released on a Tuesday afternoon without asking anyone? If not, list what prevents it — that list is the actual architecture, and the remedy for each item is more valuable than adding another service.