Skip to main content
Service-oriented architectures rely on inter-service communication governed by API contracts. Coordinating these cross-service relationships is critical for safe deployments. Ryvn’s service dependency constraints drastically reduce the manual effort involved in feature rollouts and deprecated API removal by automatically enforcing cross-service compatibility.
Looking for automated database schema migration safety? See our guide on Schema Migration Constraints.

​
The Challenge

Consider a scenario where your team builds a feature in the consumer service that calls a newly added endpoint in the provider service, which is maintained by a different team. For the feature to work in production, both services must be running compatible versions. Without automated constraint checking, you’d need to manually coordinate these deployments across teams and environments—a process prone to human error and potential outages.

​
Declaring Dependencies

Ryvn lets you declare cross-service dependencies directly in your release metadata. Suppose consumer is currently at version 0.8.0 and you’re building a new feature for version 0.9.0 that requires the new endpoint from provider 0.2.0. When merging your feature, include a dependency constraint in your service’s release file: 
# consumer-release.ryvn.yaml for version 0.9.0
dependencies:
  - service: provider
    minVersion: "0.2.0"
    maxVersion: "0.x.x"
This dependency is included in the release metadata when you publish the consumer 0.9.0 release to Ryvn.

​
How Ryvn Enforces Constraints

When Ryvn’s control plane observes the new consumer 0.9.0 release, it evaluates whether it can safely upgrade existing installations. Consider an environment with this current state: 
kind: Environment
metadata:
  name: production
spec:
  installations:
    - service: consumer  # currently running 0.8.0
    - service: provider  # currently running 0.1.0
When Ryvn considers upgrading consumer from 0.8.0 to 0.9.0, it applies dependency constraints by asking:
Do the currently installed services meet the target release’s dependency constraints?
When it loads the release dependencies for consumer 0.9.0, it discovers that the current provider 0.1.0 installation violates the new dependency constraint. 
# consumer version 0.9.0 dependencies
dependencies:
  - service: provider
    minVersion: "0.2.0"
    maxVersion: "0.x.x"
Result: Ryvn will wait to deploy the new consumer release until provider has been upgraded to a version that satisfies the constraint (any version between 0.2.0 and 0.x.x).

​
Bidirectional Constraint Enforcement

Ryvn applies service dependency constraints in both directions, preventing breaking changes from being deployed prematurely. Consider an environment with this current state: 
kind: Environment
metadata:
  name: production
spec:
  installations:
    - service: consumer  # currently running 0.8.0
    - service: provider  # currently running 0.1.0
Now imagine the owners of provider release version 1.0.0 which removes support for endpoints deprecated in 0.x.x versions. When Ryvn considers upgrading provider, it applies reverse dependency constraints by asking:
Will any currently installed services have dependency constraints violated by this upgrade?
Ryvn would refuse to deploy 1.0.0 to any environment where consumer is still running a version that declares a dependency on provider with maxVersion: 0.x.x. Result: Ryvn blocks the provider upgrade until you either: Cut a new release of consumer (e.g., 0.9.0) that is compatible with provider 1.0.0: 
# consumer-release.ryvn.yaml for version 0.9.0
dependencies:
  - service: provider
    minVersion: "1.0.0"
    maxVersion: "1.x.x"
Or modify the existing deployed release (0.8.0) on the Ryvn platform to expand its accepted version range to include provider 1.0.0: 
# consumer version 0.8.0 dependencies
dependencies:
  - service: provider
    minVersion: "0.1.0"
    maxVersion: "1.x.x"  # Expanded from "0.x.x"

​
Benefits

Service dependency constraints eliminate entire classes of production incidents: Without automated constraints, organizations typically either:
  • Require manual coordination to ensure features land in the same release cycle as their dependencies
  • Risk production outages from version mismatches
  • Spend significant time on manual remediation when things go wrong
With Ryvn’s automated constraints, you get:
  • Automatic validation of cross-service compatibility
  • Prevention of broken deployments before they happen
  • Elimination of manual coordination between teams
  • Safe, progressive rollout of breaking changes

​
Best Practices

Declare constraints at feature merge time: Add dependency constraints to release metadata when merging features that require them, not retroactively. This ensures the constraint is present when the release is published. Use version ranges to express compatibility windows: Set minVersion to the first provider version with required functionality, and maxVersion to the last known compatible major version (e.g., 0.x.x or 1.x.x). This allows Ryvn to safely upgrade within compatible versions.