Deployability Test

Service boundaries are justified by independence and are frequently assessed by domain reasoning, which is a different thing. A boundary can be conceptually clean and operationally useless.

The test is operational: can one team change, deploy and roll back without coordinating with the others?

Why it matters

Independent deployability is the entire point of a service boundary. A boundary that does not deliver it provides no benefit and imposes every cost of distribution — network calls, partial failure, distributed debugging, duplicated infrastructure, and a coordination tax paid on every feature.

The test is also cheap and unambiguous, which is unusual for architectural assessment.

Implementation patterns

Signals that the test is failing:

• A release plan with a required sequence. If service A must deploy before service B, they are not independent.
• A schema change that is a cross-team event.
• A median feature requiring changes in several services, which measures whether boundaries match how work arrives. A number above two indicates a structural problem no process improvement will fix.
• Incidents that routinely require more than two teams in the call.
• Shared libraries whose version must be aligned across services.

And the justifications that genuinely earn a boundary: independent scaling where the resource profile differs by an order of magnitude · a failure domain that must be contained · a different rate of change with a different risk profile · genuinely separate ownership with a stable interface · a technology requirement that cannot be met in the main codebase.

Team size alone is not a justification, and neither is "it is a different domain concept" — which describes a module boundary rather than a deployment one.

Industry example

Fast-growing marketplaces such as Meesho commonly split by function while work arrives by journey, so every meaningful feature crosses several services. The observable symptom is that delivery slows as the platform matures rather than speeding up, and the deployability test names the cause — which is what allows a restructuring conversation to be evidence-based rather than a matter of opinion.

Failure scenarios

• Boundaries assessed by domain reasoning alone, producing conceptual cleanliness with operational cost.
• Failure of the test answered with coordination — a programme manager, a release train — which institutionalises the tax.
• Answered by splitting further, multiplying the coordination surface.
• Consolidation treated as a career-damaging retreat, so the correct fix is never proposed.

Trade-offs

Consolidating services reduces coordination and increases blast radius: one deployable, one failure domain, and the loss of any genuinely independent scaling.

That trade is favourable when the services shared a release cadence anyway — which, if every feature needs all of them, they did. Consolidating is a legitimate architectural improvement when the split produced coordination instead of independence, and saying so plainly is frequently the hardest part.

Interview question

"You have twelve services. Pick one and tell me the last three times it was deployed independently of the others. If you cannot, tell me what that means."