Decompose by Change Cadence

Change cadence is a useful decomposition heuristic because software that changes for different reasons often benefits from different ownership and release boundaries. If one part of a system is experiment-heavy and changes weekly while another is tightly controlled and changes quarterly, forcing them to move together may create unnecessary coordination. Diverging change pressure is often a sign that one boundary is carrying more than one concern.

This heuristic is practical because it focuses on real engineering behavior rather than abstract service theory. Teams can inspect change history, deployment frequency, approval flow, and ownership friction to see whether parts of the system are being coupled artificially.

What “Change for Different Reasons” Really Means

The useful question is not just “which code changes more often?” It is:

• what business reason triggers the change?
• who usually requests it?
• who implements it?
• what level of review or control does it require?

Two areas can change at similar frequency but still belong together if they change for the same reasons. Conversely, two areas can change at different speeds and still belong together if they need one coherent transaction or model. Change cadence is a strong heuristic, not a standalone law.

Good Signals of Divergent Change Cadence

Common examples include:

• pricing rules that change through frequent experiments while invoice generation changes under tighter financial controls
• marketing-facing content flows that change daily while tenant identity policy changes rarely
• search relevance logic that evolves continuously while order settlement remains tightly audited

These patterns often suggest that one shared runtime or ownership boundary is creating avoidable coordination.

Using Change History as Evidence

One of the best uses of this heuristic is to inspect recent change history before drawing service lines. A small review table is often enough to surface the pressure.

 1change_review:
 2  pricing:
 3    cadence: weekly
 4    change_driver: experimentation
 5    owners: commerce-growth
 6  invoicing:
 7    cadence: quarterly
 8    change_driver: compliance-and-finance-policy
 9    owners: commerce-finance
10recommendation: review whether a shared boundary is forcing unnecessary coupling

What this demonstrates:

• cadence matters most when combined with reasons and owners
• a service split is more justified when the difference is persistent, not accidental
• review evidence should come from real system behavior, not just intuition

What This Heuristic Does Not Mean

It does not mean every frequently changing component deserves a service. Overusing the heuristic can lead to fragmented designs where “fast-moving” becomes a catch-all excuse for separation. Teams should still ask whether the candidate owns a coherent capability and whether the workflow can tolerate the new boundary.

Change cadence becomes strongest when it reinforces other heuristics such as business capability and ownership clarity.

Design Review Question

A team wants to split promotions away from checkout because promotions changes more often. However, the same team still owns both areas, the workflow is tightly coupled, and most changes affect the checkout interaction directly. Is change cadence alone enough?

Usually no. The stronger answer is that the higher change rate is a useful signal, but the review still needs to check whether the new boundary would reduce coordination or simply move one tightly coupled workflow across a network boundary.

Quiz Time