Dongsun Moon

Release Coupling Ratio (RCR) measures whether independent deployment actually exists. For a single change, it is the fraction of teams that must deploy together for that change to reach production. The metric was introduced by Dongsun Moon in Beyond Microservices: Building Systems That Align Architecture, Teams, and Flow (2026).

How often does deploying one service require coordinating with others? If the answer is “often,” you have a distributed monolith no matter how many repositories sit on GitHub. Independence that can’t be measured doesn’t exist.

Beyond Microservices, Chapter 2
Worked example of the Release Coupling Ratio in a system of six teams. Change 1 needs teams A, B, and C to deploy in the same release, so its RCR is 3 over 6, or 0.50. Change 2 ships with team D alone, so its RCR is 1 over 6, or 0.17. The mean over the two changes is 0.33.
A worked example, licensed under CC BY 4.0. Reuse it with attribution to “Release Coupling Ratio, Dongsun Moon, Beyond Microservices (2026)” and a link to this page.

Definition

For a change c in a system whose deployable units are owned by T teams:

RCR(c) = (teams that must deploy in the same coordinated release for c to go live) / T

The team that made the change counts in the numerator, so a change that one team can ship alone scores 1/T, the floor. Over a window such as a quarter, report the mean and the P95 across released changes. The mean shows how coupled releases are in general. The P95 shows how bad the worst coordinated releases get.

A companion number answers the question in the quote above directly: the share of changes in the window that needed more than one team to deploy together. Call it coordination frequency. RCR says how wide a coupled release is. Coordination frequency says how often one happens.

What counts and what does not

  • Counts: a team whose service must ship in the same release window or the change breaks, such as a lockstep API version, a schema change that old readers cannot handle, or a feature that fails unless both sides are live.
  • Counts: a team forced onto a shared release train for the change, even if its own code did not change.
  • Does not count: advisory code review, a heads-up message, or coordination that does not constrain when anyone deploys.
  • Does not count: changes made backward compatible so that each side can deploy in any order, for example by expanding a schema first and contracting it later.

Why it matters

Service counts, repository counts, and architecture diagrams describe structure. RCR describes behavior: whether the structure actually lets teams release on their own. A system split into many services that still releases in lockstep pays the costs of distribution without the benefit of independence. That is the distributed monolith the quote describes.

RCR is a leading indicator. It moves before lagging ones such as change failure rate, time to restore, or conversion. Coordinated releases add waiting to every change that needs them, and by Little’s Law the pending changes pile up as inventory: work in progress equals change throughput times lead time. A rising RCR shows that queue forming before it shows up as slower delivery.

Reading the number

Beyond Microservices uses RCR with three other leading indicators: Sync Hop (the number of blocking service-to-service calls on the critical user path, at P95), Ownership Coverage (the share of services with exactly one on-call owner), and Tail Index (P99 latency over the median). The book’s threshold signal for considering a split is RCR that stays high while Sync Hop at P95 repeatedly exceeds four and the Tail Index on critical paths approaches four. Its illustrative 90-day target moves RCR from 0.60 to 0.30. These are examples to calibrate against your own history, not universal limits.

How to measure it

  1. Give every change an identifier that travels into deployment records, such as the change request or the merge that started it.
  2. For each released change, list the teams whose deployments were required for it to go live. Record “required”, not just “happened at the same time”. A field in the release record or the deployment manifest is enough.
  3. Divide by the number of teams that own deployable units in the scope you measure, and keep that scope fixed between periods.
  4. Report the mean, the P95, and coordination frequency per quarter, next to deployment frequency and lead time.

How it gets misused

A target on RCR invites shallow fragmentation: splitting services so that the count of teams grows and the ratio falls while the coupling stays. Anchor any RCR target with explicit team interfaces and contract tests, so that a lower number means changes really ship alone. RCR also says nothing about runtime coupling. Two teams can release independently and still take each other down through a shared synchronous call, which is what Sync Hop and Tail Index watch.

How to cite

First published in 2026 in Beyond Microservices.

Moon, D. (2026). Beyond Microservices: Building Systems That Align Architecture, Teams, and Flow. Beyond Moon Press. ISBN 9781067722302. Release Coupling Ratio is defined in Chapter 1.

@book{moon2026microservices,
  author    = {Moon, Dongsun},
  title     = {Beyond Microservices: Building Systems That Align Architecture, Teams, and Flow},
  publisher = {Beyond Moon Press},
  year      = {2026},
  isbn      = {9781067722302},
  url       = {https://dongsunmoon.com/release-coupling-ratio/},
  note      = {Introduces the Release Coupling Ratio (Chapter 1)}
}